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Preface 



Audience 



This document describes how to create, configure, and administer an Oracle database. 



This document is intended for database administrators who perform the following 
tasks: 

■ Create an Oracle database 

■ Ensure the smooth operation of an Oracle database 

■ Monitor the operation of an Oracle database 

To use this document, you need to be familiar with relational database concepts. You 
should also be familiar with the operating system environment under which you are 
running Oracle Database. 



Documentation Accessibility 



Our goal is to make Oracle products, services, and supporting documentation 
accessible, with good usabilitv, to the disabled communit\'. To that end, our 
documentation includes features that make information available to users of assistive 
technologv. This documentation is available in HTML format, and contains markup to 
fiicilitate access bv the disabled communit\'. Accessibilit\' standards will continue to 
evolve over time, and Oracle is activelv engaged with other market-leading 
technology \'endors to address technical obstacles so that our documentation can be 
accessible to all of our customers. For more information, visit the Oracle Accessibility 
Program Web site at 

littp : / /www . oracle . com/ acces sibility/ 

Accessibility of Code Examples in Documentation 

Screen readers mav not alwa\'s correctlv read the code examples in this document. The 
conventions for writing code require that closing braces should appear on an 
otherwise emptj' line; however, some screen readers may not always read a line of text 
that consists soletv of a bracket or brace. 

Accessibility of Links to External Web Sites in Documentation 

This documentation mav contain links to Web sites of other companies or 
organizations that Oracle does not own or control, Oracle neither evaluates nor makes 
anv representations regarding the accessibilitv of these Web sites. 
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TTY Access to Oracle Support Services 

Oracle provides dedicated Text Telephone (TTY) access to Oracle Support Services 
within the United States of America 24 hours a day, 7 days a week. For TTY support, 
call 800.446.2398. Outside the United States, call +1.407.458.2479. 



Related Documents 



For more information, see these Oracle resources: 

Onick Database 2 Day DBA 

Oracle Database Concepts 

Oracle Database SQL Language Reference 

Oracle Database Reference 

Oracle Database PL/SQL Packages and Types Reference 

Oracle Database Storage Administrator's Guide 

Oracle Database VLDB and Partitioning Guide 

Oracle Database Error Messages 

Oracle Database Net Services Administrator's Guide 

Oracle Database Backup and Recovery User's Guide 

Oracle Database Performance Tuning Guide 

Oracle Database Advanced Application Developer's Guide 

Oracle Database PL/SQL Language Reference 

SQL*Plus User's Guide and Reference 

Many of the examples in this book use the sample schemas, which are instaUed by 
default when you select the Basic Installation option with an Oracle Database 
installation. Refer to Oracle Database Sample Schemas for information on how these 
schemas were created and how vou can use them vourself. 



Conventions 



The following text conventions are used in this document: 



Convention 

boldface 

italic 
monospace 



Meaning 



BoldfLice type indicates graphical user interface elements associated 
with an action, or terms defined in text or the glossary 

Italic type indicates book titles, emphasis, or placeholder variables for 
which you supply particular values. 

Monospace type indicates commands within a paragraph, URLs, code 
in examples, text that appears on the screen, or text that you enter 



What's New in Oracle Database 
Administrator's Guide? 



This section describes new features of Oracle Database II5 Release 1 (11.1) that are 
documented in this guide, and provides pointers to additional information. 

Oracle Database HgRelease 1 (11.1) New Features in the 
Administrator's Guide 

■ Simplified and improved automatic menkory management 

You can now set a single initialization parameter (MEM0RY_TARGET) to indicate 
the total amount of memor\' that is to be allocated to the database (the SGA and 
instance PGA). The svstem then automaticallv and dvnamicallv tunes all SGA and 
PGA components for optimal performance. You can still designate minimum sizes 
individually for the SGA and instance PGA. 

See "Using Automatic Memory Management" on page 5-3 

■ New fault diagnosability infrastructure to prevent, detect, diagnose, and help 
resolve critical database errors 

The goals of the fault diagnosabUity infrastructure are preventing and detecting 
problems (critical errors) proactivelv, limiting damage and interruptions after a 
problem is detected, reducing problem diagnostic time, reducing problem 
resolution time, and simplifving customer interaction with Oracle Support, The 
framework includes technologies such as health checks that run when a critical 
error occurs; proactive in-memory tracing for manv database components to 
permit first-failure data capture; an Incident Packaging Service that packages all 
diagnostic data for a problem into a zip file for transmission to Oracle Support; 
and Enterprise Manager Support Workbench, which provides a graphical 
environment for investigating, reporting, and resolving problems. Also included is 
integration with the new SQL Repair Advisor, for diagnosing and repairing 
SQL-related problems, the SQL Test Case Builder, which gathers all required 
schema and environment information to enable a SQL problem to be reproduced 
on another Oracle database, and the Data Recover^' Advisor, which helps 
diagnose, evaluate the impact of, and repair data corruptions and other data 
failures. 

See Chapter 8, "Managing Diagnostic Data" on page S-1 

■ Invisible Indexes 

Making an index invisible is an alternative to making it unusable or dropping it if 
you want to test whether overall performance will improve by removing an index. 
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An invisible index is bv default ignored bv the optimizer, but unlike an unusable 
index, is maintained during DML statements. You have the option to change an 
initialization parameter at the system or session level to cause the optimizer to use 
invisible indexes. 

See "Creating an Invisible Index" on page 19-11 

Virtual columns 

Tables can now include virtual columns. The value of a virtual column in a row is 
derived bv evaluating an expression. The expression can include columns from the 
same table, constants, SQL functions, and user-defined PL /SQL functions. In some 
cases, a virtual column eliminates the need to create a separate view. You can 
create an index on a virtual column, and you can use a virtual column as a 
partition or subpartition key. 

See "About Tables" on page 18-1. For detailed information on virtual columns, see 
Orade Database Concepts. 

Enhanced security for password-based authentication by enabling use of m.ixed 
case in passwords. 

See "Database Administrator Authentication" on page 1-14. 

Database resident connection pooling 

Database resident connection pooling (DRCP) provides a connection pool in the 
database server for typical Web application usage scenarios where the application 
acquires a database connection, works on it for a relatively short duration, and 
then releases it. DRCP pools "dedicated" servers, which are the equivalent of a 
server foreground process and a database session combined. DRCP enables 
sharing of database connections across middle-tier processes on the same 
middle-tier host and across middle-tier hosts. This results in significant reduction 
in database resources needed to support a large number of client connections, 
thereby boosting the scalabihty of both middle-tier and database tiers. 

See "About Database Resident Cormection Pooling" on page 4-4 

Table space-level encrvption 

You can encrypt any permanent tablespace to protect sensitive data. Tablespace 
encrvption is completelv transparent to vour applications. When you encrvpt a 
tablespace, all tablespace blocks are encrvpted. All segment t\'pes are supported 
for encrvption, including tables, clusters, indexes, LOBs, table and index 
partitions, and so on. 

See "Encrypted Tablespaces" on page 12-8, 

Finer-grained schema object dependencies for increased availability 

Invalidation of dependent schema objects in response to changes in the objects 
thev depend upon is greatlv reduced in Oracle Database llg, increasing 
application availabilit\' during maintenance, upgrades, and online table 
redefinition. Between a referenced object and each of its dependent objects, the 
database tracks the elements of the referenced object that are involved in the 
dependency. For example, if a single-table view selects onlv a subset of columns in 
a table, onlv those columns are involved in the dependencv. For each dependent 
of an object, if a change is made to the definition of anv element involved in the 
dependencv (including dropping the element), the dependent object is 
invalidated. Conversely, if changes are made onlv to definitions of elements that 
are not involved in the dependencv. the dependent object remains valid. 

Enhanced automated maintenance task infrastructure 



YoLL can now exercise finer control over automated maintenance task sc lied tiling. 
New installations of Oracle Database have the following default configuration for 
automated maintenance tasks and for the maintenance windows that they run in: 

- There are three automated maintenance tasks: optimizer statistics gathering, 
Automatic Segment Advisor, and Automatic SQL Tuning Advisor 

Automatic SQL Tuning Advisor examines high load SQL statements and 
makes recommendations for improving querv performance. It can he 
configured to automaticallv implement SQL profile recommendations. 

- There is a separate maintenance window for each dav of the week. All 
maintenance tasks are scheduled to run in aU maintenance windows by 
default. 

- There is a default Resource Manager plan enabled. It contains a subplan that 
limits the amount of resources that automated maintenance tasks consume. 

With Enterprise Manager or with PL /SQL package procedures, vou can change 
the start time and duration of all maintenance windows, eliminate or add 
maintenance windows, and prevent particular maintenance tasks from running in 
particular maintenance windows. You can also adjust resource allocations for 
maintenance tasks relative to each other and to your applications. 

See Chapter 24, "Managing Automated Database Maintenance Tasks". 

Encrvpting table columns using the transparent data encryption feature of Oracle 
Database now supports SecureFile LOBs. 

See Oracle Database SccurcFiles and Large Objects Developer's Guide for more 
information. 

Table compression now supported in OLTP environments 

Compressed tables now support the following operations: 

- DML statements 

- Add and drop column 

See "Consider Using Table Compression" on page 18-5. 

Result cache in the system global area 

Results of queries and querv fragments can be cached in memor\' in the result 
cache. The database can then use cached results to answer future executions of 
these queries and quen' fragments. Because retrieving results from the result 
cache is faster than rerunning a query, frequently run queries experience a 
significant performance improvement when their results are cached. 

The result cache occupies memory in the shared pool. 

See "Specif\'ing the Result Cache Maximum Size" on page 5-18, 

Enhancements to Oracle Scheduler 

Oracle Scheduler includes the following enhancements: 

- Lightweight jobs — Lightweight jobs are not schema objects like regular 
Scheduler jobs. Thev are based on a job template from which privileges and 
(in some cases) job metadata are inherited. They have a significant 
improvement in create and drop time over regular jobs because they do not 
have the overhead of creating a schema object. Use lightweight jobs when you 
need to create and drop hundreds or thousands of jobs per second. 

See "Jobs" on page 26^, 
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- Remote external jobs — A remote external job is an operating svstem 
executable that runs outside the database, is scheduled bv Oracle Scheduler, 
and runs on a host computer other than the computer running the Oracle 
database that schedules it. The remote host does not require an Oracle 
database. Instead, it has a Scheduler agent, installed separately, that the 
scheduling database communicates with to start external jobs. The agent is 
also involved in returning execution results to the scliediiling database. 

See "External Jobs" on page 26-11, 

- Extended support for Oracle Data Guard environments — Scheduler jobs can 
be designated to run only vi'hen the database is in the role of the primar}' 
database, or onlv when the database is in the role of a logical standby 
database. 

See "Scheduler Support for Oracle Data Guard" on page 26-13, 

Enhancements to Oracle Database Resource Manager 

Oracle Database Resource Manager includes the foUowing enhancements: 

- Per-session I/O limits — Sessions that exceed I/O resource consumption limits 
can be automatically switched to another consumer group. 

See 'Specif\'ing Automatic Resource Consumer Group Switching" on 
page 25-22, 

- New out-of-the-box mixed workload resource plan — Oracle Database 11^ 
includes a predefined resource plan, MIXED_WORKLOAD_P LAH, that prioritizes 
interactive operations over batch operations, and includes the required 
subplans and consumer groups recommended by Oracle, 

See "An Oracle-Supplied Mixed Workload Plan" on page 25-34, 

- New Automatic Workload Repository (AWR) snapshots of Resource Manager 
dynamic performance views, for historical statistical data on resource plan 
activations, CPU resources consumed bv consumer group, and CPU waits by 
consumer group. 

See "Monitoring Oracle Database Resource Manager" on page 25-39, 

Default automatic undo management mode 

A newlv installed llg instance defaults to automatic undo management mode, 
and if the database is created with Database Configuration Assistant, an undo 
tablespace is automatically created, A null value for the UNDO_iy[ANAGEMEISIT 
initialization parameter now defaults to automatic undo management. 

See "Overview of Automatic Undo Management" on page 14-2 

Enhanced online index creation and rebuild 

Online index creation and rebuild prior to this release required a DML-blocking 
lock at the beginning and at the end of the rebuild for a short period of time. This 
lock could delav other DML statements and therefore cause a performance spike. 
This lock is no longer required, making these online index operations fullv 
transparent. 

See "Creating an Index Online" on page 19-9, 

Abilit\' to online redefine tables that have materialized view logs 

Tables with materialized view logs can now be redefined online. Materialized 
view logs are now one of the dependent objects that can be copied to the interim 



table with the DBMS_REDEFINITION. COPY_TABLE_DEPEWDENTS package 

procedure. 

See "Redefining Tables Online" on page 18-26 

Read-only tables 

You can set iiny table to read-only mode with the ALTER TABLE statement. This 
provides an alternative to placing a table's containing tablespace in read-onlv 
mode. 

See "Placing a Table in Read-Only Mode" on page 18-25. 

Transportable tablespace enhancem.enls 

Data Pump now supports the transportable tablespace function for tablespaces 
with XMLType tables and with schema objects with XMLTypes. 

See "Transporting Tablespaces Between Databases" on page 12-29 

Optimized ALTER TABLE. ..ADD COLUMN 

For certain t\'pes of tables, when adding a column that has both a NOT NULL 
constraint and a default value, the database can optimize the resource usage and 
storage requirements for the operation. It does so bv storing the default value for 
the new column as table metadata, avoiding the need to store the value in all 
existing records. 

In addition, the follow^ing ADD COLUMN operations can now run concurrentiv with 
DML operations: 

- Add a NOT NULL column with a default value 

- Add a nullable column without a default value 

- Add a virtual column 

Enhancements to initialization parameter management 

The following enhancements are made to the handling of initialization parameters: 

- The ser\'er parameter file (SPFILE) has a new format for compliance with 
Oracle's HARD initiative. This initiative helps to prevent writing corrupted 
data to disk, and is implemented at the software and storage hardw^are levels. 

- New commands enable you to create a text initialization parameter file 
(PFILE) or server parameter file (SPFILE) from the current values of 
initialization parameters in memory. 

- Upon startup, values of initialization parameters are written to the alert log in 
such a wav as to make it easv to copy and paste them to create a new PFILE. 

- The name and path of the PFILE or SPFILE used to start the instance is written 
to the alert log. 

- Oracle Database automatically resilvers a mirrored copy of the SPFILE when 
needed. 

Data Definition Language (DDL) commands can wait for locks 

You can now set a single initialization parameter, DDL_LOCK_TIMEOUT, to specify 
how long a DDL command waits for the exclusive locks that it requires on internal 
structures before it fails. 

See "Specifying the DDL Lock Timeout" on page 2-28 
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Parti 

Basic Database Administration 



Part I provides an overview of the responsibilities of a database administrator, and 
describes liow to accomplish basic database administration tasks. It contains the 
following chapters: 

Chapter 1, "Getting Started with Database Administration" 

Chapter 2, "Creating and Configuring an Oracle Database" 

Chapter 3, "Starting Up and Shutting Down" 

Chapter 4, "Managing Processes" 

Chapter 5, "Managing Memorv" 

Chapter 6, "Managing Users and Securing the Database" 

Chapter 7, "Monitoring Database Operations" 

Chapter 8, "Managing Diagnostic Data" 



1 



Getting Started with Database 

Administration 



In this chapter: 

Tvpes of Oracle Database Users 

Tasks of a Database Administrator 

Submitting Commands and SQL to the Database 

Identifying Your Oracle Database Software Release 

About Database Administrator Security and PrivUeges 

Database Administrator Authentication 

Creating and Maintaining a Password File 

Data Utilities 



Types of Oracle Database Users 



The types of users and their roles and responsibilities depend on the database site. A 
small site can have one database administrator who administers the database for 
application developers and users. A verv large site can find it necessary to divide the 
duties of a database administrator among several people and among several areas of 
specialization. 



Database Administrators 



Each database requires at least one database administrator (DBA). An Oracle Database 
svstem can be large and can have mnnv users. Therefore, database administration is 
sometimes not a one-person job, but a job for a group of DBAs who share 
responsibilitv. 

A database administrator's responsibilities can include the following tasks: 

■ InstaUing and upgrading the Oracle Database server and apphcation tools 

■ Allocating system storage and planning future storage requirements for the 
database system 

■ Creating primary database storage structures (tablespaces) after apphcation 
developers have designed an apphcation 

■ Creating primary objects (tables, views, indexes) once application developers have 
designed an apphcation 
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Modifving the datab.ise structure, as necessary, from information given by 
application developers 

Enrolling users and maintaining system securitv 

Ensuring compliance with Oracle license agreements 

Controlling and monitoring user access to the database 

Monitoring and optimizing the performance of the database 

Planning for backup and recovery of database information 

Maintaining archived data on tape 

Backing up and restoring the database 

Contacting Oracle for technical support 



Security Officers 



In some cases, a site assigns one or more security' officers to a database. A securitv 
officer enrolls users, controls and monitors user access to the database, and maintains 
svstem securit\'. As a DBA, vou might not be responsible for these duties if your site 
has a separate securitv officer. Please refer to Oracle Database Security Guide for 
information about the duties of securitv officers. 



Network Administrators 



Some sites have one or more netivork administrators. A network administrator, for 
example, administers Oracle networking products, such as Oracle Net Services, Please 
refer to Oracle Database Net Seroiccs Adiiiiniitrator'i Guide for information about the 
duties of network administrators. 

See Also: Part V, "Distributed Database Management", for 
information on network administration in a distributed 
environment 



Application Deveiopers 



Application developers design and implement database apphcations. Their 
responsibilities include the following tasks: 

Designing and developing the database application 

Designing the database structure for an application 

Estimating storage requirements for an application 

Specifying modifications of the database structure for an application 

Relaying this information to a database administrator 

Tuning the application during development 

Establishing security measures for an application during development 

Application developers can perform some of these tasks in collaboration with DBAs. 
Please refer to Oracle Dalahase Advairccil Application Developer's Guide for information 
about application development tasks. 
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Application Administrators 

An Oracle Database site can assign one or more application administrators to 
administer a particular application. Each application can have its own administrator 



Database Users 



Database users interact with the database through applications or utilities, A tvpical 
user's responsibilities include the following tasks: 

■ Entering, modifying, and deleting data, where permitted 

■ Generating reports from the data 

Tasks of a Database Administrator 

The following tasks present a prioritized approach for designing, implementing, and 
maintaining an Oracle Database: 

Task 1: Evaluate the Database Server Hardware 

Task 2: Install the Oracle Database Software 

Task 3: Plan the Database 

Task 4: Create and Open the Database 

Task 5: Back Up the Database 

Task 6: Enroll System Users 

Task 7: Implement the Database Design 

Task 8: Back Up the Fully Functional Database 

Task 9: Tune Database Performance 

Task 10: Download and Install Patches 

Task 11: Roll Out to Additional Hosts 

These tasks are discussed in the sections that follow. 

Note: When upgrading to a new release, back up vour existing 
production environment, both software and database, before 
installation. For information on preserving your existing 
production database, see Oracle Database Upgrade Guide. 

Task 1 : Evaluate the Database Server Hardware 

Evaluate how Oracle Database and its applications can best use the available computer 
resources. This evaluation should reveal the following information: 

■ How manv disk drives are available to the Oracle products 

■ How manv, if anv, dedicated tape drives are available to Oracle products 

■ How much memorv is available to the instances of Oracle Database you will run 
(see your system configuration documentation) 
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Task 2: Install the Oracle Database Software 

As the database administrator, you install the Oracle Database server software and 
any front-end tools and database applications that access the database. In some 
distributed processing installations, the database is controlled bv a central computer 
(database server) and the database tools and applications are executed on remote 
computers (chents). In this case, you must also install the Oracle Net components 
necessarv to connect the remote machines to the computer that executes Oracle 
Database. 

For more information on what software to install, see "Identifying Your Oracle 
Database Software Release" on page 1-11. 

See Also: For specific requirements and instructions for 
installation, refer to the following documentation: 

■ The Oracle documentation specific to your operating system 

■ The installation guides for your front-end tools and Oracle Net 
drivers 

Task 3: Plan the Database 

As the database administrator, vou must plan: 

■ The logical storage structure of the database 

■ The overaU database design 

■ A backup strategy for the database 

It is important to plan how the logical storage structure of the database will affect 
svstem performance and various database management operations. For example, 
before creating any tablespaces for your database, vou should know how manv 
datafiles will make up the tablespace, what t\'pe of information will be stored in each 
tablespace, and on which disk drives the datafiles will be physically stored. When 
planning the overall logical storage of the database structure, take into account the 
effects that this structure will have when the database is actually created and running. 
Consider how the logical storage structure of the database will affect: 

■ The performance of the computer executing running Oracle Database 

■ The performance of the database during data access operations 

■ The efficiency of backup and recovery procedures for the database 

Plan the relational design of the database objects and the storage characteristics for 
each of these objects. Bv planning the relationship between each object and its phvsical 
storage before creating it, \'ou can directlv affect the performance of the database as a 
unit. Be sure to plan for the growth of the database. 

In distributed database environments, this planning stage is extremely important. The 
physical location of frequentiv accessed data dramatically affects application 
performance. 

During the planning stage, develop a backup strategy for the database. You can alter 
the logical storage structure or design of the database to improve backup efficiency. 

It is bevond the scope of this book to discuss relational and distributed database 
design. If you are not familiar with such design issues, please refer to accepted 
industry-standard documentation. 
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Part II, "Oracle Database Structure and Storage", and Part III, "Schema Objects", 
provide specific information on creating logical storage structures, objects, and 
integrity constraints for your database. 



Task 4: Create and Open the Database 



After vou complete the database design, you can create the database and open it for 
normal use. You can create a database at installation time, using the Database 
Configuration Assistant, or you can supply your own scripts for creating a database. 

Please refer to Chapter 2, "Creating and Configuring an Oracle Database", for 
information on creating a database and Chapter 3, "Starting Up and Shutting Dow^n" 
for guidance in starting up the database. 



Task 5: Back Up the Database 



After vou create the database structure, carry out the backup strategy vou planned for 
the database. Create any additional redo log files, take the first full database backup 
(online or offline), and schedule future database backups at regular intervals. 

See Also: Oracle Database Backup and Recovery User's Guide 



Task 6: Enroll System Users 



After you back up the database structure, you can enroll the users of the database in 
accordance with your Oracle license agreement, and grant appropriate privileges and 
roles to these users. Please refer to Chapter 6, "Managing Users and Securing the 
Database" for guidance in this task. 



Task?: Implement the Database Design 

After you create and start the database, and enroll the svstem users, you can 
implement the planned logical structure database bv creating all necessarj' 
tablespaces. When you have finished creating tablespaces, vou can create the database 
objects. 

Part II, "Oracle Database Structure and Storage" and Part III, "Schema Objects" provide 
information on creating logical storage structures and objects for your database. 

Task 8: Back Up the Fully Functional Database 

When the database is fully implemented, again back up the database. In addition to 
regularlv scheduled backups, you should always back up vour database immediately 
after implementing changes to the database structure. 

Task 9: Tune Database Performance 

Optimizing the performance of the database is one of your ongoing responsibilities as 
a DBA. Oracle Database provides a database resource management feature that helps 
you to control the allocation of resources among various user groups. The database 
resource manager is described in Chapter 25, "Managing Resource Allocation with 
Oracle Database Resource Manager". 

See Also: Oracle Database Performance Tuning Guide for 
information about tuning your database and applications 
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Task 10: Download and Install Patches 



After mstallation and on a regular basis, download and install patches. Patches are 
available as single interim patches and as patchsets (or patch releases). Interim, 
patches address individual software bugs and may or mav not be needed at your 
installation. Patch releases are collections of bug fixes that are applicable for all 
customers. Patch releases have release numbers. For example, if you installed Oracle 
Database 10.2.0.0, the first patch release will have a release number of 10.2.0.1. 

See Also: Oracle Database InsfalSation Guide for vour platform for 
instructions on downloading and installing patches. 



Task 11 : Roll Out to Additional Hosts 



After vou have an Oracle Database installation properly configured, tuned, patched, 
and tested, you mav want to roll that exact installation out to other hosts. Reasons to 
do this include the following: 

■ You ha\'e multiple production database systems, 

■ You want to create development and test systems that are identical to your 
production system. 

Instead of installing, tuning, and patching on each additional host, you can clone your 
tested Oracle Database installation to other hosts, saving time and eliminating 
inconsistencies. There are two tvpes of cloning available to you: 

■ Cloning an Oracle home — Just the configured and patched binaries from the 
Oracle home directory and subdirectories are copied to the destination host and 
"fixed" to match the new en\'ironment. You can then start an instance with this 
cloned home and create a database. 

You can use the Enterprise Manager Clone Oracle Home tool to clone an Oracle 
home to one or more destination hosts. You can also manually clone an Oracle 
home using a set of provided scripts and Oracle Universal Installer 

■ Cloning a database — The tuned database, including database files, initialization 
parameters, and so on, are cloned to an existing Oracle home (possibly a cloned 
home). 

You can use the Enterprise Manager Clone Database tool to clone an Oracle 
database instance to an existing Oracle home. 

See Also: 

■ Oracle Universal Installer and OPatch User's Guide and Enterprise 
Manager online help for details on how to clone an Oracle home, 

■ Enterprise Manager online help for instructions for cloning a 
database. 



Submitting Commands and SQL to the Database 



The primary means of communicating with Oracle Database is by submitting SQL 
statements, Oracle Database also supports a superset of SQL, which includes 
commands for starting up and shutting down the database, modifying database 
configuration, and so on. There are three ways to submit these SQL statements and 
commands to Oracle Database: 

■ Directly, using the command-line interface of SQL'Plus 

■ Indirectly, using the graphical user interface of Oracle Enterprise Manager 
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With Oracle Enterprise Manager (Enterprise Manager), voii use an intuitive 
grapiiical interface to administer the database, and Enterprise Manager submits 
SQL statements and commands behind the scenes. 

See Oracle Dnbibiisc 2 Day DBA for more information. 

■ Directly, using SQL Developer 

Developers use SQL Developer to create and test database schemas and 
applications, although vou can also use it for database administration tasks. 

See Oracle Database 2 Day Devchper'i Guide for more information. 

This section focuses on using SQL'Plus to submit SQL statements and commands to 
the database. It includes the following topics: 

. About SQL'Plus 

■ Connecting to the Database with SQL'Plus 



About SQL'Plus 

SQL*PliLS is the primarv command-line interface to vour Oracle database. You use 
SQL*PliLS to start up and shut down the database, set database initialization 
parameters, create and manage users, create and alter database objects (such as tables 
and indexes), insert and update data, run SQL queries, and more. 

Before you can submit SQL statements and commands, vou must connect to the 
database. With SQL*Plus, vou can connect locally or remotelv. Connecting locally 
means connecting to an Oracle database running on the same computer on which you 
are running SQL'Plus, Connecting remotely means connecting over a neh,vork to an 
Oracle database that is running on a remote computer Such a database is referred to 
as a remote database. The SQL'Plus executable on the local computer is provided bv a 
full Oracle Database installation, an Oracle Client installation, or an Instant Client 
instaUation, 

See Also: SQL-Plm User's Guide and Reforence 

Connecting to the Database with SQL*Plus 

Oracle Database is composed of the Oracle instance, which is a collection of Oracle 
processes and memorv, and a set of disk files that contain user data and svstem data. 
When you connect with SQL'Plus, vou are connecting to the Oracle instance. Each 
instance has an instance ID, also known as a svstem ID (SID). Because there can be 
more than one Oracle instance on a host computer, each with its own set of data files, 
you must identifv the instance to which I'ou w^ant to connect. For a local connection, 
you identify the instance by setting operating svstem envirormient variables. For a 
remote connection, vou identifv the instance by specifying a network address and a 
database service name. In addition, for both local and remote connections, vou must 
set environment variables to help the operating system find the SQL'Plus executable 
and to provide the executable with a path to its support files and scripts. To connect to 
an Oracle instance with SQL'Plus, therefore, you must complete the following steps; 

Step 1; Open a Command Window 

Step 2: Set Operating System Environment Variables 

Step 3: Start SQL'Plus 

Step 4; Submit the SQL'Plus CONNECT Statement 

See Also: Oracle Database Concepts for background information 
about the Oracle instance 
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Step 1: Open a Command Window 

Take the necessarv action on your platform to open a window into w^liich vou can 
enter operating system commands. 



Platform Action 



UNIX and Linux Open d termindl session 

Windows Open .1 ComniLind Prompt window 

Use tliis command window for steps 2 though 4, 

Step 2: Set Operating System Environment Variables 

Depending on vour platform, you may have to set environment variables before 
starting SQL'Plus, or at least verif\' that they are set properlv. 

For example, on most platforms, OEACLE_SID and ORACLE_HOME must be set. In 
addition, it is advisable to set the PATH environment variable to include the 
ORACLE_HOME /bin director}'. Some platforms mav require additional environment 
variables. On the UNIX and Linux platforms, you must set environment variables by 
entering operating svstem commands. On the Windows platform, Oracle Universal 
Installer (OUI) automatically assigns values to ORACLE_HOME and ORACLE_SID in the 
Windows registry. If vou did not create a database upon installation, OUI does not set 
OEACLE_SID in the registry; after vou create vour database at a later time, you must 
set the ORACLE_SID environment variable from a command window. 

UNIX and Linux installations come with two scripts, oraenv and coraenv, that you 
can use to easily set environment variables. For more information, see Administrator's 
Reference for UNIX S\/steins. 

For all platforms, when switching between instances with different Oracle homes, you 
must change the ORACLE_HOME environment variable. If multiple instances share the 
same Oracle home, you must change onlv ORACLE_SID when switching instances. 

Refer to the Oracle Database IiislaUntion Guide or administration guide for your 
operating s\'stem for details on envirorunenl variables and for information on 
switching instances. 

Example 1-1 Setting Environment Variables in UNIX (C Shell) 

aetenv OEACI£_SID orcl 

aetenv ORACI£_H0ME /u01/app/oracle/prod.-uct/ll.l , a/db_l 

setenv LD_LIBRARY_PATH $ORACLE_HOHE/lib: /usr/lib: /usr/dt/lib: /usr/apenwin/lib: /usr/ccs/lib 

Example 1-2 Setting Environment Variables in Windows 

SET ORACLE_SID=orcl 

Example 1-2 assumes that ORACLE_HOME is set in the registry and that ORACLE_SID 
is not set (or that you want to override the registr}" value of ORACLE_SID to connect to 
a different instance). 

On Windows, environment variable values that vou set in a command prompt 
window override the values in the registry. 

Step 3: Start SOL*Pius 

To start SQLTlus: 
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1. Do one of the following: 

■ Ensure that the PATH environment variable contains ORACLE_HOME /hin. 
, Change directory to ORACLE_HOME /bin. 

2. Enter the following command (case sensitive on UNIX and Linux): 

sglplijs /nolog 

Step 4: Submit the SOL*Plus CONNECT Statement 

You submit the SQL'Plus CONMECT statement to initially cormect to the Oracle 
instance or at any time to leconnect as a different user. The syntax of the CONWECT 
statement is as follows: 

[;OHN[ECT] [logon] [flS {SYSOPER | SYS DBA) ] 

The syntax of logon is as follows: 

{username \ / ] [Sconiiect_identifier] 

When you provide useriianie, SQL*Plus prompts for a password. The password is 
not echoed as you type it. 

The following table describes the syntax components of the COHNECT statement. 



Syntax Component 



Description 



/ Calls for external authentication of the connection request A 

database password is not used in this type of authentication. 
The most common form of external authentication is operating 
system authentication, where the database user is 
authenticated bv having logged in to the host operating 
system with a certain host user account. External 
authentication can also be performed with an Oracle wallet or 
by a network service. See Oracle Database Secutitf/ Guide for 
more information. See also "Using Operating System 
Authentication" on page 1-18. 



AS [SYSOPER SYSDBA) 



Indicates that the database user is connecting with either the 
SYSOPER or SYSDBA system privilege. Only certain predefined 
administrative users or users who have been added to the 
password file may connect with these privileges. See 
"Adm.inistrative Privileges" on page 1-15 for more information. 



usern^me 



A valid database user name. The database authenticates the 
connection request by matching usern^me against the data 
dictionary and prompting for a user password. 



connect_idenfcifiez"(l) 



An Oracle Net connect identifier, for a remote connection. The 
exact syntax depends on the Oracle Net configuration. If 
omitted, SQL'Plus attempts connection to a local instance. 

A common connect identifier is a net service name. This is an 
alias for an Oracle Net connect descriptor (network address 
and database service name). The alias is typically resolved in 
the tnsnames.ora file on the local computer, but can be 
resolved in other ways. 

See Orncle Database Net Services Administrator 's Guide for more 
information on connect identifiers. 
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Syntax Component 



Description 



connsc t_ident i fier {2) 



As an alterniitive, a connect identifier can use cmi/ connect 
syntax. Easy connect provides out-of-the-box TCP/IP 
connectivity tor remote databases without having to configure 
Oracle Net Services on the chent (local) computer. 

Easy connect syntax for the connect identifier is as follows: 

host[:poTtl [/service_jjarael 

viihere: 

■ host is the host name or IP address of the computer 
hosting the remote database. 

■ port is the TCP port on which the Oracle Net listener on 
host listens for database connections. If omitted, 1521 is 
assumed. 

■ service_naine is the database service name. Can be 
omitted if the Net Services listener configuration on the 
remote host designates a default service. If no default 
service is configured, ssrvics_n3ine must be supplied. 
Each database typically offers a service ivith a name equal 
to the global database name. An example would be 
Orel .my company .ccan. See "Defining Database Services" 
on page 2-40 for more mformation. 

See Oracle Database Net Services Administrator's Guide for more 
information on easy connect. 



Example 1-3 

This simple example connects to a local database as user SYSTEM. SQL'Plus prompts 
for the SYSTEM user password. 

connect system 

Example 1-4 

This example connects to a local database as user SYS with the SYSDBA privilege. 
SQL*Plus prompts for the SYS user password. 

connect sys as sysdba 

When connecting as user SYS, you must connect AS SYSDBA, 

Example 1-5 

This example connects locally vi'ith operating system authentication. 

connect / 

Example 1-6 

This example connects locally with the SYSDBA priyilege v^fith operating system 
authentication, 

connect / as sysdba 

Example 1-7 

This example uses easy connect svntax to connect as user sales admin to a remote 
database running on the host dbl . mycompany . com. The Oracle Net listener (the 
listener) is listening on the default port (1521), The database service is 

sales .mycompany. com, SQL'Plus prompts for the sales admin user password. 
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connect salesadminedbl.mycompany .com/sales .my company .com 

Example 1-8 

This example is identical to Example 1—7, except that the listener is listening on the 
non-default port number 1522. 

connect salesadmin8dlil.inycoinpany.com: 152 2 /sales .niycong>any.com 

Example 1-9 

This example connects remotely as user salesadmin to the database service 
designated bv the net service name sales 1. SQL*Plus prompts for the salesadmin 
user password. 

connect salesadminSsalesl 

Example 1-10 

This example connects remotely with external authentication to the database service 
designated by the net service name sales 1. 

connect /Ssalesl 

Example 1-11 

This example connects remotelv with the SYSDBA privilege and with external 
authentication to the database service designated by the net service name salesl. 

connect /Ssalesl as sysdlia 

See Also: 

■ "Using Operating System. Authentication" on page 1-18 

■ SQL'Plus User's Guide and Reference for more information on the 
CONNECT statement 

■ Oracle Database Net Services Adminisiraior's Guide for more 
information on net service names 

Identifying Your Oracle Database Software Release 

Because Oracle Database continues to evolve and can require maintenance, Oracle 
periodically produces new releases. Not all customers initially subscribe to a new 
release or require specific maintenance for their existing release. As a result, multiple 
releases of the product exist simultaneously. 

As manv as five numbers mav be required to fullv identify a release. The significance 
of these numbers is discussed in the sections that follow. 

Release Number Format 

To understand the release nomenclature used bv Oracle, examine the following 
example of an Oracle Database server labeled "Release 10.1.0.1.0". 
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Figure 1-1 Example of an Oracle Database Release Number 



10. 



Major dalabase ' 

release number 

Database maintenance - 
release number 



.0. 



.0 



I Platform specific 

release number 

I — Component specific 
release number 



I — Application server 
release number 



Note: Starting with, release 9,2, maintenance releases of Oracle 
Database are denoted by a change to the second digit of a release 
number In previous releases, the third digit indicated a particular 
maintenance release. 



Major Database Release Number 

The first digit is the most general identifier It represents a major new version of the 
software that contains significant new functionality. 

Database Maintenance Release Number 

The second digit represents a maintenance release level. Some new features may also 
be included. 

Application Server Reiease Number 

The third digit reflects the release level of the Oracle Application Sen'er (OracleAS), 

Component-Specific Release Number 

The fourth digit identifies a release level specific to a component. Different 
components can have different numbers in this position depending upon, for example, 
component patch sets or interim releases, 

Piatform-Speclfic Release Number 

The fifth digit identifies a platform-specific release. Usually this is a patch set. When 
different platforms require the equivalent patch set, this digit will be the same across 
the affected platforms. 



Checking Your Current Release Number 



To identify the release of Oracle Database that is currently installed and to see the 
release levels of other database components vou are using, querv the data dictionary 
view PRODUCT_COMPONENT_VERSION, A sample query follows, (You can also query 
the V5VERSI0N view to see component- lev el information,) Other product release 
levels may increment independent of the database server, 

COL PRODUCT FORMAT A3 5 

COL VERSION FORMAT A15 

COL STATUS FORMftT A15 

SELECT ' FROM PR0DUCT_C0MPOHENT_VERSIOH; 

PRODUCT VERSIOM STATUS 

HLSRTL 10,2.0,1.0 Production 
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Oracle Database lOg Enterprise Edition 1D.2.0.1.D Prod 
PL/SQL 10.2.0.1.0 Production 



It is important to convev to Oracle the results of this query when vou report problems 
with the software. 



About Database Administrator Security and Privileges 

To perform the administrative tasks of an Oracle Database DBA, vou need specific 
privileges within the database and possibly in the operating system of the server on 
which the database runs. Access to a database administrator's account should be 
tightly controlled. 

This section contains the following topics: 

■ The Database Administrator's Operating Svstem Account 

■ Administrative User Accounts 

The Database Administrator's Operating System Account 

To perform manv of the administrative duties for a database, you must be able to 
execute operating svstem commands. Depending on the operating svstem on which 
Oracle Database is running, vou might need an operating svstem account or ID to gain 
access to the operating system. If so, your operating svstem account might require 
operating system privileges or access rights that other database users do not require 
(for example, to perform Oracle Database software installation). Although you do not 
need the Oracle Database files to be stored in your account, vou should have access to 
them. 

See Also: Your operating svstem specific Oracle documentation. 
The method of creating the account of the database administrator is 
specific to the operating system. 

Administrative User Accounts 

Two administrative user accounts are automatically cieated when Oracle Database is 
installed: 

■ SYS (default password: CHANGE_ON_INSTALL) 

■ SYSTEM (default password; MAMAGER) 



Note: Both Oracle Universal Installer (OUI) and Database 
Configuration Assistant (DBCA) now prompt for SYS and SYSTEM 
passwords and do not accept the default passwords 
"ch ange_on_in stall ' or "manager", respectively. 

If you create the database manually, Oracle strongly recommends 
that you specifv passwords for SYS and SYSTEM at database 
creation time, rather than using these default passwords. Please 
refer to "Protecting Your Database: Specif\'ing Passwords for Users 
SYS and SYSTEM" on page 2-15 for more information. 
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Create at least one additional administrative user and grant to that user an appropriate 
administrative role to use when performing daily administrative tasks. Do not use SYS 
and SYSTEM for these purposes. 



Note Regarding Security Enhancements: In this release of Oracle 
Database and in subsequent releases, several enhancements are 
being made to ensure the securit;' of default database user 
accounts. You can find a security' checklist for this release in Oracle 
Database Security Guide. Oracle recommends that vou read this 
checklist and configure your database accordingly. 

SYS 

When vou create an Oracle Database, the user SYS is automaticallv created and 
granted the DBA role, 

AH of the base tables and views for the database data dictionar}' are stored in the 
schema SYS. These base tables and views are critical for the operation of Oracle 
Database. To maintain the integrit\" of the data dictionarv, tables in the SYS schema 
are manipulated onlv by the database. Thev should never be modified bv anv user or 
database administrator, and no one should create any tables in the schema of user 
SYS. (However, vou can change the storage parameters of the data dictionary settings 
if necessary.) 

Ensure that most database users are never able to connect to Oracle Database using the 
SYS account. 

SYSTEM 

When you create an Oracle Database, the user SYSTEM is also automatically created 
and granted the DBA role. 

The SYSTEM username is used to create additional tables and views that dispiav 
administrative information, and internal tables and views used by various Oracle 
Database options and tools. Never use the SYSTEM schema to store tables of interest to 
no n- administrative users. 

The DBA Role 

A predefined DBA role is automatically created with every Oracle Database 
installation. This role contains most database svstem privileges. Therefore, the DBA 
role should be granted only to actual database administrators. 

Note: The DBA role does not include the SYSDBA or SYSOPER 
svstem privileges. These are special administrative privileges that 
allow an administrator to perform basic database administration 
tasks, such as creating the database and instance startup and 
shutdown. These system privileges are discussed in 
"Administrative Privileges" on page 1-15. 

Database Administrator Authentication 

As a DBA, you often perform special operations such as shutting down or starting up 
a database. Because only a DBA should perform these operations, the database 
administrator usernames require a secure authentication scheme. 
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This section contains the following topics: 

■ Administrative Privileges 

■ Selecting an Authentication Method for Database Administrators 

■ Using Operating System Authentication 

■ Using Password File Authentication 



Administrative Privileges 



Administrative privileges that are required for nn administrator to perform basic 
database operations are granted through two special svstem privileges, SYSDBA and 
SYSOPER. You must have one of these privileges granted to you, depending upon the 
level of authorization you require. 

Note: The SYSDBA and SYSOPER system privileges allow access 
to a database instance even when the database is not open. Control 
of these privileges is totally outside of the database itself. 

The SYSDBA and SYSOPER privileges can also be thought of as 
types of connections that enable vou to perform certain database 
operations for which privileges cannot be granted in anv other 
fiishion. For example, you if vou have the SYSDBA privilege, you 
can connect to the database hy specifying CONNECT AS SYSDBA, 

SYSDBA and SYSOPER 

The foUowing operations are authorized by the SYSDBA and SYSOPER system 
privileges: 

System Privilege Operations Authorized 



SYSDBA 



SYSOPER 



Perform STARTUP and SHUTDOWH operations 

ALTER DATABASE: open, mount, back up, or change character set 

CREATE DATABASE 

DROP DATABASE 

CREATE SPFILE 

ALTER DATABASE ARCHIVELOG 

ALTER DATABASE RECOVER 

Includes the RESTRICTED SESSIOH privilege 

Effectively, this system privilege allows a user to connect as user SYS. 

Perform STARTUP and SHUTDOWN operations 

CREATE SPFILE 

ALTER DATABASE OPEH /MO DHT/ BACKUP 

ALTER DATABASE ARCHIVELOG 

ALTER DATABASE RECOVER (Complete recovery only Any form 

of incomplete recovery, such as UNTIL 

TIME I CHAHGE | CAMCEL | COHTROLFILE requires connecting as 

SYSDBA) 

■ Includes the RESTRICTED SESSIOH privilege 

This privilege allows a user to perform basic operational tasks, but 
without the abilitv to look at user data. 
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The mdnner in which vou. are authorized to use these privileges depends upon the 
method of authentication that you use. 

When you connect with SYSDBA or SYSOPER privileges, you connect with a default 
schema, not with the schema that is generallv associated with vour username. For 
SYSDBA this schema is SYS; for SYSOPER the schema is PUBLIC. 

Connecting with Administrative Priviieges: Example 

This example illustrates that a user is assigned another schema (SYS) when connecting 
with the SYSDBA system privilege. Assume that the sample user oe has been granted 
the SYSDBA svstem privilege and has issued the following statements: 

CONNECT oe 

CREATE TftBLE admin.test (name VRRCHftS2 ( 20) | ; 

Later, user oe issues these statements: 

COHNECT oe AS SYSDBA 
SELECT ' FROM adminjest; 

User oe now receives the following error: 

ORA-00942: table or view does not exist 

Having connected as SYSDBA, user oe now references the SYS schema, but the table 
was created in the oe schema. 

See Also: 

■ "Using Operating System Authentication" on page 1-lS 

■ "Using Password File Authentication" on page 1-19 

Selecting an Authentication Method for Database Administrators 

Database Administrators can authenticate through the database data dictionar\', 
(using an account password) like other users. Keep in mind that beginning with Oracle 
Database 11^ Release 1, database passwords are case sensitive. (You can disable case 
sensitivity and return to pre-Release 11^^ behavior bv setting the 
3EC_caSE_SENSITIVE_L0G0N initialization parameter to FALSE.) 

In addition to normal data dictionarv authentication, the following methods are 
available for authenticating database administrators with the SYSDBA or SYSOPER 
privilege: 

■ Operating system (OS) authentication 

■ A password file 

■ Strong authentication with a network-based authentication service, such as Oracle 
Internet Directory 

These methods are required to authenticate a database administrator when the 
database is not started or otherwise unavailable. (They can also be used when the 
database is available.) 

The remainder of this section focuses on operating system authentication and 
password file authentication. See Oracle Database Scciir/fy Guide for information about 
authenticating database administrators with network-based authentication services. 
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Notes: 



These methods replace the CONNECT INTERNAL syntax 
provided with earlier versions of Oracle Database. CONNECT 
INTERNAL is no longer supported. 

Operating s\'stem authentication takes precedence over 
password file authentication. If vou meet the requirements for 
operating system authentication, then even if you use a 
password file, vou will be authenticated by operating system 
a uthenticatlon. 



Your choice will be influenced by w^hether you intend to administer your database 
locallv on the same machine where the database resides, or whether you intend to 
administer many different databases from a single remote client. Figure 1-2 illustrates 
the choices you have for database administrator authentication schemes. 

Figure 1-2 Database Administrator Authentication l\3etliods 



Remote Databaso 
Administration 



Local Database 
Administration 




If vou are performing remote database administration, consult vour Oracle Net 
documentation to determine whether vou are using a secure connection. Most popular 
connection protocols, such as TCP/IP and DECnet, are not secure. 

See Also: 

■ Oracle Database Security Guide for information about 
authenticating database administrators with network-based 
authentication services. 

■ Orach' Database Net Services Administrator's Guide 

Nonsecure Remote Connections 

To connect to Oracle Database as a privileged user over a nonsecure connection, you 
must be authenticated by a password file. When using password file authentication, 
the database uses a password file to keep track of database usernames that have been 
granted the SYSDBA or SYSOPER system privilege. This form of authentication is 
discussed in Using Password File Authentication" on page 1-19. 
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Local Connections and Secure Remote Connections 

You can connect to Oracle Database as a privileged user over a local connection or a 
secure remote connection in two ways: 

■ If the database has a password file and you have been granted the SYSDBA or 
SYSOPER system privilege, then you can connect and be authenticated bv a 
password file. 

■ If the server is not using a password file, or if you have not been granted SYSDBA 
or SYSOPER privileges and are therefore not in the password file, vou can use 
operating system authentication. On most operating systems, authentication for 
database administrators involves placing the operating svstem username of the 
database administrator in a special group, generically referred to as OSDBA. Users 
in that group are granted SYSDBA privileges. A similar group, OSOPER, is used to 
grant SYSOPER privileges to users. 



Using Operating System Authentication 



This section describes how to authenticate an administrator using the operating 
svstem. 

OSDBA and OSOPER 

Two special operating system groups control database administrator connections 
when using operating svstem authentication. These groups are generically referred to 
as OSDBA and OSOPER, The groups are created and assigned specific names as part 
of the database installation process. The specific names vary depending upon your 
operating system and are listed in the following table: 

Operating System Group UNIX User Group Windows User Group 

OSDBA dba ORA_DBA 

OSOPER oper ORA_OPER 

The default names assumed by the Oracle Universal Installer can be overridden. How 
you create the OSDBA and OSOPER groups is operating system specific. 

Membership in the OSDBA or OSOPER group affects your coruiection to the database 
in the following ways: 

■ If you are a member of the OSDBA group and you specify AS SYSDBA when you 
connect to the database, then you connect to the database with the SYSDBA system 
privilege. 

■ If vou are a member of the OSOPER group and vou specify AS SYSOPER when 
you connect to the database, then you connect to the database with the SYSOPER 
system privilege. 

■ If you are not a member of either of these operating system groups and you 
attempt to connect as SYSDBA or SYSOPER, the CONNECT command fails. 

See Also: Your operating system specific Oracle documentation 
for iniormation about creating the OSDBA and OSOPER groups 

Preparing to Use Operating System Authentication 

To enable operating system authentication of an administrative user: 
1. Create an operating system account for the user. 
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2. Add the account to the OSDBA or OSOPER operating svstem defined groups. 

Connecting Using Operating System Autlientication 

A user can be authenticated, enabled as an administrative user, and connected to a 
local database by t\'ping one of the following SQL*Plus commands: 

COHHECT / AS 3YSDBA 
COHHECT / AS 3YS0PES 

For the Windows platform onlv, remote operating svstem authentication over a secure 
connection is supported. You must specify the net service name for the remote 
database: 

COHHECT / (?nefc_service_naroe A3 SY3DBA 
COHHECT / @net_service_ijarae AS SYSOPER 

Both the client computer and database host computer must be on a Windows domain. 

See Also: 

■ "Connecting to the Database with SQL*Plus" on page 1-7 

■ SQL'Phis User's Guide and Reference for syntax of the CONNECT 
command 



Using Password File Authentication 



This section describes how to authenticate an administrative user using passw^ord file 
authentication. 

Preparing to Use Password File Authentication 

To enable authentication of an administrative user using password file authentication 
you must do the following: 

1. If not alreadv created, create the password file using the ORAPWD utihty: 

ORAPWD FILE=fiIeijaine EHTRIE3 =raax_users 

See "Creating and Maintaining a Password File" on page 1-21 for details. 



Notes: 

■ When vou invoke Database Configuration Assistant (DBC A) as 
part of the Oracle Database installation process, DBCA creates a 
password file. 

■ Beginning with Oracle Database ll;j Release 1, passwords in the 
password file are case sensitive unless vou include the 

IGNORECASE = Y command-Une argument. 

2. Set the REMOTE_LOGIN_PASSWORDFILE initialization parameter to EXCLUSIVE, 
(This is the default). 

Note: REM0TE_L0GIN_PA3SW0RDFILE is a static initialization 
parameter and therefore cannot be changed without restarting the 
database. 
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3. Connect to the database as user SYS (or as another user with the administrative 
privileges). 

4. If the user does not already exist in the database, create the user and assign a 
password. 

Keep in mind that beginning with Oracle Database 11;^ Release 1, database 
passwords are case sensitive. (You can disable case sensitivit\' and return to 
pre-Release lit; behavior by setting the SEC_CASE_SEWSITIVE_LOGOW 
initialization parameter to FALSE, 

5. Grant the SY3DBA or SYSOPER system privilege to the user: 

GRAHT SYSDBA to oe; 

This statement adds the user to the password file, thereby enabhng connection AS 

SYSDBA. 

See Also: "Creating and Maintaining a Password File" on 

page 1-21 for instructions for creating and maintaining a password 

file. 

Connecting Using Password File Authentication 

Administrative users can be connected and authenticated to a local or remote database 
by using the SQL'Plus CONNECT command. They must connect using their username 
and password and the AS SYSDBA or AS SYSOPER clause. Note that beginning with 
Oracle Database llg Release 1, passwords are case-sensitive unless the password file 
was created with the IGWOEECASE = Y option. 

For example, user oe has been granted the SYSDBA privilege, so oe can connect as 
follows: 

COHHECT oe AS SYSDBA 

However, user oe has not been granted the SYSOPER privilege, so the following 
command will fail: 

COHNECT oe AS SYSOPER 



Note: Operating system authentication takes precedence over 
password file authentication, Specificallv, if vou are a member of 
the OSDBA or OSOPER group for the operating system, and you 
connect as SYSDBA or SYSOPER, vou will be connected with 
associated administrative privileges regardless of the 
iiicrmvne/password that vou specifv. 

If vou are not in the OSDBA or OSOPER groups, and vou are not in 
the password file, then attempting to connect as SYSDBA or as 
SYSOPER fails. 



See Also: 

■ "Connecting to the Database w^ith SQL "Plus" on page 1-7 

■ SQL^Pliis User's Guide ami Reference for syntax of the CONNECT 
command 
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Creating and Maintaining a Password File 

You can create a password file using the password file creation utility, ORAPWD, For 
some operating systems, you can create this file as part of your standard installation. 

This section contains the following topics: 

. Using ORAPWD 

. Setting REMOTE_LOGlN_ PASSWORDFILE 

■ Adding Users to a Password File 

■ Maintaining a Password File 

See Also: 

■ "Using Password File Authentication" on page 1-19 

■ "Selecting an Authentication Method for Database 
Administrators" on page 1-16 

Using ORAPWD 

The syntax of the ORAPWD command is as follows: 

ORAPWD FILE=filejianie [ ENTRIES =nurausers] 

[FORCE= (Y| U] ] [IGHORECASE= {Y| H] ] [NOSYSDBA= {Y | H) ] 

Command arguments are summarized in the following table. 

Argument Description 

FILE Nijme to lissign to the password file. See your operating system 

documentation for name retjuirements. You must supply a complete path. If 
you supply only a file name, the file is written to the current directory 

ENTRIES (Optional) Maximum number of entries (user accounts) to permit in the file. 

FORCE (Optional) If y, permits overwriting an existing password file. 

IGHOHECASE (Optional) If y, passwords are treated as case-msensitive, 

NOSYSDBA (Optional) For Data Vault installations. See the Data Vault installation guide 

for your platform for more information. 

There are no spaces permitted around the equal-to (=) character. 

The command prompts for the SYS password and stores the password in the created 
password file. 

Example 

The following command creates a password file named oraipwoircl that allows up to 
30 privileged users with different passwords. 

□rapwd FILE=Drapworcl ENTRIES=30 

ORAPWD Command Line Argument Descriptions 

The following sections describe tlie ORAPWD command line arguments. 

FILE 

This argument sets the name of the password file being created. You must specify the 
full path name for the file. If vou supply only a file name, the file is written to the 



Getting Started with Database Administration 1-21 



Crealing and Mainlaining a Password File 



current directory. The contents of this file are encrypted, and the file cannot be read 
directly. This argument is mandatorv. 

The types of filenames allowed for the password file are operating svstem specific. 
Some operating systems require the password file to adhere to a specific format and be 
located in a specific directory. Other operating systems allow the use of environment 
variables to specify the name and location of the password file. For name and location 
information for the Unix and Linux operating systems, see Admitiisfralor's Reference for 
UNIX-Based Operating Systems. For Windows, see Ptafforiii Guide for Microsoft Windows. 
For other operating systems, see your operating system documentation. 

If you are running multiple instances of Oracle Database using Oracle Real 
Application Clusters, the environment variable for each instance should point to the 
same password file. 



Caution: It is critically important to the security of your system 
that you protect your password file and the environment variables 
that identify the location of the password file. Any user with access 
to these could potentially compromise the security of the 
connection. 



ENTRIES 

This argument specifies the number of entries that you require the password file to 
accept. This number corresponds to the number of distinct users allowed to connect to 
the database as SYSDBA or SYSOPER. The actual number of allowable entries can be 
higher than the number of users, because the ORAPWD utility continues to assign 
password entries until an operating system block is filled. For example, if your 
operating system block size is 512 bytes, it holds four password entries. The number of 
password entries allocated is always a multiple of four. 

Entries can be reused as users are added to and removed from the password file. If 
you intend to specify REM0TE_L0GIN_PASSWORDFILE= EXCLUSIVE, and to allow the 
granting of SYSDBA and SYSOPER privileges to users, this argument is required. 

Caution: When you exceed the allocated number of password 
entries, you must create a new password file. To avoid this 
necessity, allocate a number of entries that is larger than you think 
vou will ever need. 



FORCE 

This argument, if set to Y, enables you to overwrite an existing password file. An error 
is returned if a password file of the same name already exists and this argument is 
omitted or set to N, 

IGNORECASE 

If this argument is set to y, passwords are case-insensitive. That is, case is ignored 
when comparing the password that the user supplies during login with the password 
in the password file. 

See Also: Oracle Database Security Guide for more information about 
case-sensitivity in passwords. 
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Setting REMOTE_LOGIN_ PASSWORDFILE 

In addition to creating tlie password file, you must also set the initialization parameter 
REMOTE_LOGIN_PASSWORDFILE to the appropriate value. The values recognized are: 

■ NONE: Setting this parameter to NONE causes Oracle Database to behave as if the 
password file does not ex ist. That is, no privileged coruiections are allowed over 
nonsecure connections. 

■ EXCLUSIVE: (The default) An EXCLUSIVE password file can be used with only 
one instance of one database. Onlv an EXCLUSIVE file can be modified. Using an 
EXCLUSIVE password file enables vou to add, modif\', and delete users. It also 
enables vou to change the SYS password with the ALTER USER command. 

■ SHARED: A SHARED password file can be used bv multiple databases running on 
the same server, or multiple instances of an Oracle Real Application Clusters 
(RAC) database. A SHARED password file cannot be modified. This means that you 
cannot add users to a SHARED password file. Any attempt to do so or to change 
the password of SYS or other users with the SYSDBA or SYSOPER privileges 
generates an error All users needing SYSDBA or SYSOPER system privUeges must 
be added to the password file when REMOTE_LOGIN_PASSWORDFILE is set to 
EXCLUSIVE. After all users are added, you can change 
REMOTE_LOGIN_PASSWORDFILE to SHARED, and then share the fUe. 

This option is useful if you are adm.inistering multiple databases or a RAC 
database. 

If REMOTE_LOGIN_PASSWORDFILE is set to EXCLUSIVE or SHARED and the password 
file is missing, this is equivalent to setting REMOTE_LOGIN_PASSWORDFILE to NONE. 



Note: You cannot change the password for SYS if 
REMOTE_LOGIN_PASSWORDFILE is set to SHARED. An error 
message is issued if you attempt to do so. 



Adding Users to a Password File 



When you grant SYSDBA or SYSOPER privileges to a user, that user's name and 
privilege information are added to the password file. If the server does not have an 
EXCLUSIVE password file (that is, if the initialization parameter 

REMOTE_LOGIN_PASSWORDFILE is NONE or SHARED, or the password file is missing), 
Oracle Database issues an error Lf you attempt to grant these privileges. 

A user's name remains in the password file only as long as that user has at least one of 
these b,vo privileges. If you revoke both of these privileges, Oracle Database removes 
the user from the password fUe. 

Creating a Password File and Adding New Users to It 

Use the following procedure to create a password and add new users to it: 

1 . Follow the instructions for creating a password file as explained in "Using 
ORAPWD" on page 1-21. 

2. Set the REMGTE_LOGIN_PASSWORDFILE initialization parameter to EXCLUSIVE. 
(This is the default.) 
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Note: REMOTE_LOGIN_PASSWORDFILE is a static initialization 
parameter and therefore cannot be changed without restarting the 
database. 



3. Conned with SYSDBA privileges as shown in the following example, and enter the 
SYS password when prompted: 

COMMECT SYS flS SYSDBA 

4. Start up the instance and create the database if necessary, or mount and open an 
existing database. 

5. Create users as necessary. Grant SYSDBA or SYSOPER privileges to vourself and 
other users as appropriate. See "Granting and Revoking SYSDBA and SYSOPER 
Privileges", later in this section. 

Granting and Revoking SYSDBA and SYSOPER Privileges 

If vour server is using an EXCLUSIVE password file, use the GRANT statement to grant 
the SYSDBA or SYSOPER system privilege to a user, as shown in the following 
example: 

GRAHT SYSDBA TO oe; 

Use the REVOKE statement to revoke the SYSDBA or SYSOPER system privilege from a 
user, as shown in the following example: 

REVOKE SYSDBA FROM oe; 

Because SYSDBA and SYSOPER are the most powerful database privileges, the WITH 
ADMIN OPTION is not used in the GRANT statement. That is, the grantee cannot in turn 
grant the SYSDBA or SYSOPER privilege to another user Only a user currently 
connected as SYSDBA can grant or revoke another user's SYSDBA or SYSOPER system 
privileges. These privileges cannot be granted to roles, because roles are available only 
after database startup. Do not confuse the SYSDBA and SYSOPER database privileges 
with operating system roles. 

See Also: Ornclc Database Seairiiy Guide for more information on 
system privileges 

Viewing Password File Members 

Use theVSPWFILE_USERS view to see the users who have been granted SYSDBA or 
SYSOPER system privileges for a database. The columns displayed by this view are as 
follows: 



Column Description 

OSERHAME This column contains the name of the user that is recognized by the 

pasEvvord file. 

SYSDBA If the value of this column is TRUE, then the user can log on with 

SYSDBA system privileges. 

SYSOPER If the value of this column is TRUE, then the user can log on with 

SYSOPER system privileges. 
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Maintaining a Password File 

This section describes how to: 

■ Expand the number of password file users if the password file becomes full 

■ Remove the password file 

Expanding the Number of Password File Users 

If you receive the file full error (ORA-1996) when you try to grant SYSDBA or 
SYSOPER system privileges to a user, you must create a larger password file and 
regrant the privileges to the users. 

Replacing a Password File 

Use the following procedure to replace a password file: 

1. Identifv the users who have SYSDBA or SYSOPER privileges by quer}'ing the 

VSPWFILE_USERS view. 

2. Delete the existing password file. 

3. Follow the instructions for creating a new password file using the ORAPWD utilitv 
in "Using ORAPWD" on page 1-21. Ensure that the ENTRIES parameter is set to a 
number larger than you think you will ever need. 

4. Follow the instructions in "Adding Users to a Password File" on page 1-23. 

Removing a Password File 

If vou determine that you no longer require a password file to authenticate users, vou 
can delete the password file and then optionally reset the 

REMOTE_LOGIN_PASSWORDFILE initialization parameter to HOHE. After you remove 
this file, only those users who can be authenticated by the operating system can 
perform SYSDBA or SYSOPER database administration operations. 

Data Utilities 

Oracle utilities are available to help vou maintain the data in your Oracle Database. 

SQL'Loader 

SQL*Loader is used both by database administrators and by other users of Oracle 
Database. It loads data from standard operating system files (such as, files in text or C 
data format) into database tables. 

Export and Import Utilities 

The Data Pump utilit}' enables vou to archive data and to move existing data between 
one Oracle Database and another Also available is the original Import utilitv for 
importing data from earlier releases. Beginning with Release 11^, the original Export 
utilit;' is desupported for general use and is recommended only in very specific 
circumstances. 

See Also: Oracle Database Utilities for detailed information about 
these utilities 
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Creating and Configuring an Oracle 

Database 



In this chapter: 

About Creating an Oracle Database 

Creating a Database with DBCA 

Creating a Database with the CREATE DATABASE Statement 

Understanding the CREATE DATABASE Statement 

Understanding Initialization Parameters 

Troubleshooting Database Creation 

Dropping a Database 

Managing Initialization Parameters Using a Server Parameter File 

Defining Database Services 

Considerations After Creating a Database 

Database Data Dictionary Views 

See Also: 

■ Chapter 15, "Using Oracle-Managed Files" for information 
about creating a database whose underlying operating Bvstem 
files are automaticnllv created and managed by the Oracle 
Database server 

■ Your platform -specific Oracle Real Application Clusters (RAC) 
installation guide for information about creating a database in 
an Oracle RAC environment 



About Creating an Oracle Database 



After you plan your database using some of the guidelines presented in this section, 
you can create the database with a graphical tool or a SQL command. You typically 
create a database during Oracle Database software installation. However, you can also 
create a database after installation. Reasons to create a database after installation are as 
follows: 

■ You used Oracle Universal Installer (OUI) to install software only, and did not 
create a database. 
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■ YoLL want to create iinother database (and database instance) on the same host 
computer as an existing Oracle database. In this case, this chapter assumes that the 
new database uses the same Oracle home as the existing database. You can also 
create the database in a new Oracle home bv running OUI again. 

■ You want to make a copy of (clone) a database. 
The specific methods for creating a database are: 

■ With Database Configuration Assistant (DBCA), a graphical tool. 
See "Creating a Database with DBCA" on page 2-4 

■ With the CREATE DATABASE SQL statement. 

See "Creating a Database with the CREATE DATABASE Statement" on page 2-4 

Considerations Before Creating the Database 

Database creation prepares several operating svstem files to work together as an 
Oracle Database. You need only create a database once, regardless of how many 
datafiles it has or how many instances access it. You can create a database to erase 
information in an existing database and create a new database with the same name 
and phvsical structure. 

The following topics can help prepare you for database creation. 

■ Planning for Database Creation 

■ Meeting Creation Prerequisites 

Planning for Database Creation 

Prepare to create the database bv research and careful planning. Table 2—1 lists some 
recommended actions: 



Table 2-1 Database Planning Tasks 



Action 



Additional Information 



Pliin the ddtdbase tables and indexes and estimate the amount of 
sp^ce they will require. 



Part II, "Oracle Dat.ibdse 
Structure and Storage" 

Part III, "Schema Objects" 



Plan the layout of the underlying operating system, files your 
database will comprise. Proper distribution of files can improve 
database performance dramatically by distributing the I/O during 
file access. You can distribute I /O in several ways when you install 
Oracle software and create your database. For example, you can 
place redo log files on separate disks or use striping. You can 
situate datafiles to reduce contention. And you can control data 
density (number of rows to a data block). If you create a Flash 
Recovery Area, Oracle recommends that you place it on a storage 
device that is different from that of the datafiles. 



Consider using Oracle-managed files and Automatic Storage 
Management to create and manage the operating svstem files that 
make up your database storage. 



Oracle Database 
Performance Tunings Guide 

Oi'acle Database Backup 
and Recovery User's Guide 

Your Oracle operating 
system-specific 
documentation, 
including the 
appropriate Oracle 
Database installation 
guide. 

Chapter 15, "Using 
Oracle-Managed Files" 

0>-acle Database Storage 
Administrator's Guide 
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Table 2-1 (Cont.) Database Planning Tasks 



Action 



Additional Information 



Sslect the global database name, which is the name and location of 
the database within the network structure. Create the global 
database name bj' setting both the DBJfiME and DB_DOMAIN 
initialization parameters. 

Familiarize yourself with the initialization parameters contained in 
the initialization parameter file. Become famihar with the concept 
and operation of a server parameter file. A server parameter file 
lets you store and manage vour initialization parameters 
persistently in a server-side disk file. 



"Determining the Global 
Database Name" on 
page 2-25 

"Understanding 

Initialization Parameters" 
on page 2-23 

"Wliat Is a Server 
Parameter File?" on 
page 2-31 

Oracle Database Reference 



Select the database character set. 

All character data, including data in the data dictionary, is stored in 
the database character set. You must specif;' the database character 
set when you create the database. 

If clients using different character sets will access the database, then 
choose a superset that includes all client character sets. Otherwise, 
character conversions maybe necessary at the cost of increased 
overhead and potential data loss. 

You can also specify an alternate character set. 

Caution: AL3 2UTF8 is the Oracle Database character set that is 
appropriate for XMLType data. It is equivalent to the lANA 
registered standard UTF-S encoding, which supports all valid XML 
characters. 

Do not confuse Oracle Database database character set DTF8 (no 
hyphen) with database character set AL3 2DTF8 or with character 
eucodmg UTF-8. Database character set DTF8 has been superseded 
by AL3'2UTF8. Do not use DTF8 for XML data. UTF8 supports only 
Unicode version 3.1 and earlier; it does not support all valid XML 
characters, AL32UTF8 has no such limitation. 

Using database character set U'TF8 for XML data could potentially 
cause a fatal error or affect security negatively If a character that is 
not supported by the database character set appears in an 
input-document element name, a replacement character (usually 
"?") is substituted for it. This will terminate parsing and raise an 
exception. 

Consider what time zones your database must support 

Oracle Database uses one of two time zone files as the source of 
valid time zones. The default time zone file is timezonelrg. dat. 
It contains more time zones than the other time zone file, 
t:iinezone . dat. 

Select the standard database block size. This is specified at database 
creation by the DB_BLOCK_SIZE initialization parameter and 
cannot be changed after the database is created. 

The SYSTEM tahlespace and most other tablespaces use the 
standard block size. Additionally, you can specify up to four 
nonstandard block sizes when creating tablespaces. 

Determine the appropriate initial sizing for the SYSAUX tablespace. 



Oi'acle Database 
GlobaUzaticin Support 
Gil hie 



"Specifying the Database 
Time Zone File" on 
page 2-21 



"Specifying Database 

Block Sizes" on page 2-27 



"About the SYSAUX 
Tablespace" on page 2-16 



Plan to use a default tablespace for non-SYSTEM users to prevent 
inadvertent saving of database objects in the SYSTEM tablespace. 



"Creating a Default 
Permanent Tablespace" 
on page 2-18 
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Table 2-1 (Cont.) Database Planning Tasks 



Action Additional information 

Pliin to use an undo tablespace to manage your undo data. Chapter 14, "Managing 

Undo" 

Develop a backup and recovery strategy to protect the database Chapter 10, "Managing 

from failure. It is important to protect the control file by the Redo Log" 

multiplexing, to choose the appropriate backup mode, and to „, , ,, ,„ , 

iL r J !■ J J 1 Chapter 11, Managmg 

manaee the onlme and arcluved redo ioes. , ,. jn j r n 

" " Archived Kedo Logs 

Chapter 9, "Managing 
Control Files" 

Oracle Database Backup 
and RECovcry User's Guide 

Familiarize yourself with the principles and options of starting up Chapter 3, "Starting Up 
and shutting down an instance and mounting and opening a and Shutting Down" 

database. 

Meeting Creation Prerequisites 

Before vou can create a new database, the following prerequisites must be met: 

■ The desired Oracle softivare must be installed. This includes setting various 
environment variables unique to vour operating system and establishing the 
directory structure for software and database files. 

■ Sufficient memory must be available to start the Oracle Database instance. 

■ Sufficient disk storage space must be available for the planned database on the 
computer that runs Oracle Database. 

All of these are discussed in the Oracle Database InstaUalion Guide specific to your 
operating system. If vou use the Oracle Universal Installer, it will guide vou through 
your installation and provide help in setting environment variables and establishing 
directory structure and authorizations. 

Creating a Database with DBCA 

Database Configuration Assistant {DBCA} provides a graphical interface and guided 
workflow for creating and configuring a database. It is the preferred way to create a 
database, because it is a more automated approach, and your database is readv to use 
when DBCA completes. DBCA can be launched by the Oracle Universal Installer 
(OUI), depending upon the type of install that vou select. You can also launch DBCA 
as a standalone tool at any time after Oracle Database instaUation. 

See Oracle Database 2 Day DBA for detailed information about creating a database with 
DBCA. 

Creating a Database with the CREATE DATABASE Statement 

Using the CREATE DATBASE SQL statement is a more manual approach to creating a 
database. One advantage of using the CREATE DATABASE statement is that you can 
use it in a script and run the script as often as necessarv. 

If you use the CREATE DATABASE statement, you must complete additional actions 
before you have an operational database. These actions include building views on the 
data dictionarv tables and installing standard PL/SQL packages. You perform these 
actions by running prepared scripts. 
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If voLi have existing scripts for creating vour database, consider editing those scripts to 
take advantage of new Oracle Database features. 

The instructions in this section apply to single-instance instaHalions onl^. Refer to the 
Oracle Real Application Clusters (Oracle RAC) installation guide for vour platform for 
instructions for creating an Oracle RAC database. 

Note: Singk- instance does not mean that onlv one Oracle instance can 
reside on a single host computer In fact, multiple Oracle instances 
(and their associated databases) can run on a single host computer. A 
single-instance database is a database that is accessed by onlv one 
Oracle instance, as opposed to an Oracle RAC database, which is 
accessed concurrently bv multiple Oracle instances on multiple nodes. 
See Oracle Real Application Clusters Administration and Deployment 
Guide for more information on Oracle RAC. 



Complete the following steps to create a database with the CREATE DATABASE 
statement. The examples create a database named mynewdb. 

Step 1; Specify an Instance Identifier (SID) 

Step 2; Ensure That the Required Environment Variables Are Set 

Step 3: Choose a Database Administrator Authentication Method 

Step 4; Create the Initialization Parameter File 

Step 5; {Windows Only) Create an Instance 

Step 6: Connect to the Instance 

Step 7; Create a Server Parameter File 

Step 8: Start the Instance 

Step 9: Issue the CREATE DATABASE Statement 

Step 10: Create Additional Tablespaces 

Step 11: Run Scripts to Build Data Dictionary Views 

Step 12: Run Scripts to Install Additional Options (Optional) 

Step 13: Back Up the Database. 

Step 14: (Optional) Enable Automatic Instance Startup 

Tip: If vou are using Oracle Automatic Storage Management (ASM) 
to manage vour disk storage, you must start the ASM instance and 
configure vour disk groups before performing these steps. For 
information about Automatic Storage Management, see Oracle 
Database Storage Administrator's Guide. 



Step 1 : Specify an Instance Identifier (SID) 



Decide on a unique Oracle system identifier (SID) for vour instance, open a command 
window, and set the ORACLE_SID environment variable. Use this command windows 
for the subsequent steps. 

OEACLE_SID is used to distinguish this instance from other Oracle Database instances 
that you may create later and run concurrently on the same host computer. The 
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maximum, number of characters for ORACLE_SID is 12, and onlv letters .ind numeric 
digits are permitted. On some platforms, the SID is case-sensitive. 

Note: It is common practice to set the SID to be equal to the database 
name. The maximum number of characters for the database name is 
eight. For more information, see the discussion of the DB_NAME 
initialization parameter in Oracle Database Reference. 

The following example for UNIX and Linux operating systems sets the SID for the 
instance that you will connect to in Step 6: Connect to the Instance; 

■ Bourne, Bash, or Korn shell: 

OEAC LE_S I D=inynewiib 
export ORACLE_SID 

. C sheU: 

setenv ORACLE_SID n^Tiewdb 

The following example sets the SID for the Windows operating system; 

set ORACLE_SID=ii^raewdb 

See Also: Oracle Database Concepts for background information 
about the Oracle instance 

Step 2: Ensure That the Required Environment Variabies Are Set 

Depending on vour platform, before you can start SQL*Plus (as required in Step 6; 
Connect to the Instance), you may have to set environment variables, or at least verify 
that thev are set properly. 

For example, on most platforms, OEACLE_SID and ORACLE_HOME must be set. In 
addition, it is advisable to set the PATH variable to include the ORACLE_HOME /bin 
directory'. On the UNIX and Linux platforms, vou must set these environment 
variables manually. On the Windows platform, OUl automatically assigns values to 
OEACLE_HOME and ORACLE_SID in the Windows registry. If you did not create a 
database upon installation, OUI does not set ORACLE_SID in the registrv, and you will 
have to set the ORACLE_SID environment variable when you create your database 
later. 

Step 3: Choose a Database Administrator Authentication Method 

You must be authenticated and granted appropriate svstem privileges in order to 
create a database. You can authenticate as an administrator with the required 
privileges in the following ways: 

■ Wilh a password file 

■ With operating system authentication 

In this step, you decide on an authentication method. 

If vou decide to authenticate with a password file, create the password file as 
described in "Creating and Maintaining a Password File" on page 1-21. If you decide to 
authenticate with operating svstem authentication, ensure that you log in to the host 
computer with a user account that is a member of the appropriate operating system 
user group. On the UNIX and Linux platforms, for example, this is t\'picallv the dba 
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user group. On the Windows platform., the user instalhng the Oracle software is 
automatically placed in the required user group. 



See Also: 

■ "About Database Administrator Securit}' and Privileges" on 
page 1-13 

■ "Database Administrator Authentication" on page 1-14 for 
information about password files and operating system 
authentication 

Step 4: Create the Initialization Parameter File 

When an Oracle instance starts, it reads an initialization parameter file. This file can be 
a text file, which can be created and modified with a text editor, or a binary file, which 
is created and dvnamicallv modified bv the database. The binary file, which is 
preferred, is called a server parameter file. In this step, vou create a text initialization 
parameter file. In a later step, vou create a server parameter file from the text file. 

One wav to create the text initialization parameter file is to edit the sample presented 
in "Sample Initialization Parameter File" on page 2-24. 

For convenience, store vour initialization parameter file in the Oracle Database default 
location, using the default file name. Then when vou start your database, it will not be 
necessary to specify the PFILE clause of the STARTUP command, because Oracle 
Database automatically looks in the default location for the initialization parameter 
file. 

For the default name and location of the initialization parameter file for your platform, 
see "Understanding Initialization Parameters" on page 2-23, 

See Also: Oracle Dalabasf Rejerciice for details on all initiahzation 
parameters 

Step 5: (Windows Only) Create an Instance 

On the Windows platform, before vou can connect to an instance, you must manually 
create it if it does not already exist. The ORADIM command creates an Oracle instance 
by creating a new Windows service. 

To create an instance: 

■ Enter the following command at a Windows command prompt: 

□radim -HEW -SID sid -STARTMODE MANUAL -PFILE pfile 

where sid is the desired SID (for example mynewdb) and pfile is the full path to 
the text initialization parameter file. This command creates the instance but does 
not start it. 

Warning: Do not set the - STARTMODE argument to AUTO at this 
point, because this causes the new instance to start and attempt to 
mount the database, which does not exist vet. You can change this 
parameter to AUTO, if desired, in Step 14, 



Creating and Configuring an Oracle Database 2-7 



Crealing a Database with the CREATE DATABASE Statement 



See the section "Using ORADIM to Administer an Oracle Database Instance" in Oracle 
Database Platform Guide for Microsoft Windows tor more information on ttie ORADIM 
command. 



Step 6: Connect to the Instance 



Start SQL*Plus and connect to your Oracle Database instance with the SYSDBA system 
privilege. 

■ To authenticate with a password file, enter the following commands, and then 
enter the SYS password when prompted: 

$ sqlplus /nolog 

SQL> COHNECT SYS AS SYSDBA 

■ To authenticate with operating system authentication, enter the following 
commands: 

5 sqlplus /nolog 

SQL> COHNECT / A3 SYSDBA 

SQL*Plus outputs the foUowing message: 

Connected to an idle instance. 



Note: SQL'Plus may output a message similar to the following: 

Connected to: 

Oracle Database llg Enterprise Edition Release 11.1.0.5.0 - Production 

With the Partitioning, OLAP and Data Mining options 

If so, this means that the instance is already started. You may have 
connected to the wrong instance. Exit SQL*Plus with the EXIT command, 
check that ORACLE_SID is set property, and repeat this step. 



Step 7: Create a Server Parameter File 



The server parameter file enables you to change initialization parameters with the 
ALTER SYSTEM command and persist the changes across a database shutdown and 
startup. You create the server parameter file from your edited text initialization file. 

The following SQL'Plus command reads the text initialization parameter file (PFILE) 
with the default name from the default location, creates a server parameter file 
(SPFILE) from the text initialization parameter file, and writes the SPFILE to the 
default location with the default SPFILE name. 

CREATE SPFII£ FROM PFII£; 

You can also supply the file name and path for both the PFILE and SPFILE if you are 
not using default names and locations. 

Tip: The database must be restarted before the server parameter file 
takes effect. 
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Note: Although creating a server parameter file is optional at this 
point, it is recommended.. If you do not create a server parameter file, 
the instance continues to read the text initialization parameter fUe 
whenever it starts. 

Imporlant — If you are using Oracle- managed files and your 
initialization parameter file does not contain the CONTROL_FILES 
parameter, you must create a server parameter file now so the 
database can save the names and location of the control files that it 
creates during the CREATE DATABASE statement. See "Specifj'ing 
Oracle-Managed Files at Database Creation" on page 2-18 for more 
information. 



See Also: 



■ "Managing Initialization Parameters Using a Server Parameter 
File" on page 2-31 

■ Oracle Database SQL Language Reference for more information on 
the CREATE SPFILE command 

Step 8: Start the Instance 

start an instance without mounting a database. Typically, you do this only during 
database creation or while performing maintenance on the database. Use the STARTUP 
command with the NOMOUWT clause. In this example, because the initialization 
parameter file or server parameter file is stored in the default location, you are not 
required to specify the PFILE clause: 

STARTUP KOHODHT 

At this point, the instance memory is allocated and its processes are started. The 
database itself does not yet exist. 

See Also: 

■ Oracle Database Concepts for an overview of the Oracle instance. 

■ "Managing Initialization Parameters Using a Server Parameter 
File" on page 2-31 

■ Chapter 3, "Starting Up and Shutting Down", to learn how to 
use the STARTUP command 

Step 9: Issue the CREATE DATABASE Statement 

To create the new database, use the CREATE DATABASE statement. 

Example 1 

The following statement creates database mynewdb. This database name must agree 
with the DB_NAME parameter in the initialization parameter file. This example assumes 
the following: 

■ The initialization parameter file specifies the number and location of control files 
with the CONTROL_FILES parameter 

■ The directory /uOl/app/ oracle/ oradata/mynewdb exists. 
CREATE DATABASE mynewdb 
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USER SYS IDENTIFIED BY sys_j)assword 
USER SYSTEM IDENTIFIED BY system_pdssword 

LOGFILE GROUP 1 { ' /uOl/app/oracle/oradata/n^newdb/redoOl .log' | SIZE lOOM, 
GROUP 2 {'/u01/app/oracle/oradata/inynewdb/redo02.1og') SIZE lOOM, 
GROUP 3 {'/u01/app/oracle/oradata/n^newdb/redo03.1og') SIZE lOOM 
MASLOGFILES 5 
KAXLOGMEHBERS 5 
MMLOGHISTORY 1 
MAXDATAFILES 100 
CHARACTER SET US7ASCII 
HATIOHAL CHARACTER SET AL16DTF16 
EXTENT MAMAGEHENT LOCAL 

DATAFILE '/uOl/app/oracle/oradata/mynewdb/systemOl .dbf ' SIZE 325H REUSE 
SYSADX DATAFILE 7u01/app/oracle/oradata/raynewdb/sysaux01.dbf ' SIZE 325H REUSE 
DEFAOLT TABLESPACE users 

DATAFILE ' /uOl/app/oracle/oradata/mynewdl)/ users 01 .dtf ' 

SIZE 500M REUSE AUTOEXTEND ON MAXSIZE UHLIMITED 
DEFAULT TEMPORARY TABLESPACE temptsl 

TEMPFILE '/uOl/app/oracle/aradata/mynewdL/tempOl.dbf ' 

SIZE 20M REUSE 
UNDO TABLESPACE undotbs 

DATAFILE '/uOl/app/oracle/oradata/mynewdb/undotbsOl .dbf 

SIZE 200M REUSE AUTOEXTEND ON MAXSIZE UHLIMITED; 

A database is created widi the following characteristics: 

■ The database is named mynewdb. Its global database name is 

mynewdb.us .oracle . com, where the domain portion (us .oracle . com) is 
taken from the initialization fUe, See "Determining the Global Database Name" on 
page 2-25. 

■ Three control files are created as specified by the CONTROL_FILES initialization 
parameter, which was set before database creation in the initialization parameter 
file. See "Sample Initialization Parameter File" on page 2-24 and "Specifying 
Control Files" on page 2-26, 

■ The passwords for user accounts SYS and SYSTEM are set to the values that vou 
specified. Beginning with Release 11^, the passwords are case-sensitive. The two 
clauses that specify the passwords for SYS and SYSTEM are not mandatory in this 
release of Oracle Database. However, if you specify either clause, vou must specify 
both clauses. For further information about the use of these clauses, see "Protecting 
Your Database: Specifying Passwords for Users SYS and SYSTEM" on page 2-15. 

■ The new database has three redo log files as specified in the LOGFILE clause. 
MAXLOGFILES, MAXLOGMEMBEES, and MAXLOGHISTORY define limits for the redo 
log. See Chapter 10. "Managing the Redo Log", 

■ MAXDATAFILES specifies the maximum number of datafiles that can be open in 
the database. This number affects the initial sizing of the control file. 
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Note: You can set several limits during database creation. Some of 
these limits are limited by and affected bv operating system limits. 
For example, if you set MAXDATAFILES, Oracle Database allocates 
enough space in the control file to store MAXDATAFILES filenames, 
even if the database has onlv one datafile initially. However, 
because the maximum control file size is limited and operating 
system dependent, you might not be able to set all CREATE 
DATABASE parameters at their theoretical maximums. 

For more information about setting limits during database creation, 
see the Oracle Database SQL Uuiguagc Reference and ;'our operating 
system-specific Oracle documentation. 

The US7ASCII character set is used to store data in this database, 

TheAL15UTF15 character set is specif ied as the NATIONAL CHARACTER SET, 
used to store data in columns specifically defined as HCHAR, NCLOB, or 

NVARCHAR2. 

The SYSTEM tablespace, consisting of the operating system file 

/uDl/app/ oracle/ oradata/mynewdb/ systemDl . dbf is created as specified 
bv the DATAFILE clau.se. If a file with that name already exists, it is overwritten. 

The SYSTEM tablespace is created as a locally managed tablespace. See "Creating a 
Locally Managed SYSTEM Tablespace" on page 2-15, 

A SYSAUX tablespace is created, consisting of the operating system file 

/uOl / app/ oracle/ oradata/mynewdb/ sysauxDl . dbf as specified in the 
SYSAUX DATAFILE clause. See "About the SYSAUX Tablespace" on page 2-16, 

The DEFAULT TABLESPACE clause creates and names a default permanent 
tablespace for this database. 

The DEFAULT TEMPORARY TABLESPACE clause creates and names a default 
temporary tablespace for this database. See "Creating a Default Temporary 
Tablespace" on page 2-18, 

The UHDO TABLESPACE clause creates and names an undo tablespace that is used 
to store undo data for this database if you have specified 

UI]DO_MANAGEMENT=AUTO in the initialization parameter file. If you omit this 
parameter, it defaults to AUTO. See "Using Automatic Undo Management: 
Creating an Undo Tablespace" on page 2-17. 

Redo log files will not initially be archived, because the ARCHIVELOG clause is not 
specified in this CREATE DATABASE statement This is customarv during database 
creation. You can later use an ALTER DATABASE statement to switch to 
ARCHIVELOG mode. The initialization parameters in the initialization parameter 
file for mynewdb relating to archiving are L0G_ARCHIVE_DEST_1 and 
L0G_ARCHIVE_F0RMAT. See Chapter 11, "Managing Archived Redo Logs". 
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Troubleshooting: 

■ Ensure that aJl directories exist. The CREATE DATABASE statement 
does not create directories. 

■ If you are not using Oracle-managed files, every tablespace clause 
must include a DATAFILE or TEMPFILE clause. 

■ If vou receive nn error message that contains a process number, 
examine the trace file for that process. See "Finding Trace Files" on 
page 8-19 for more information. Look for the trace file that 
contains the process number in the trace file name. 

■ Use the alert log as another source for investigating errors. See 
"Viewing the Alert Log" on page 8-18. 

Example 2 

This example illustrates creating a database with Oracle Managed Files, which enables 
you to use a much simpler CREATE DATABASE statement. To use Oracle Managed 
Files, the initialization parameter DB_CREATE_FILE_DEST must be set This 
parameter defines the base directorv for the various database files that the database 
creates and automatically names. The following statement is an example of setting this 
parameter in the initialization parameter file: 

DB_CEEATE_FILE_DEST='/u01/app/oracle/oradata' 

With Oracle Managed Files and the following CREATE DATABASE statement, the 
database creates the SYSTEM and SYSAUX tablespaces, creates the additional 
tablespaces specified in the statement, and chooses default sizes and properties for all 
datafiles, control files, and redo log files. Note that these properties and the other 
default database properties set bv this method mav not be suitable for your 
production environment, so it is recommended that you examine the resulting 
configuration and modifv it if necessary. 

CREATE DATABASE mynewdb 

USER SYS IDENTIFIED BY sys_password 

USER SYSTEM IDEHTIFIED BY system_pdsswoird 

EKTEHT MAMAGEMENT LOCAL 

DEFAULT TEMPORARY TABLESPACE temp 

UNDO TABLESPACE undotbsl 

DEFAULT TABLESPACE users; 

Troubleshooting: If your create DATABASE statement fails, and if 
you did not complete Step 7, ensure that there is not a pre-existing 
server parameter file (SPFILE) for this instance that is setting 
initialization parameters in an unexpected way. For example, an 
SPFILE contains a setting for the complete path to all control files, and 
the CREATE DATABASE statement fails if those control files do not 
exist. Ensure that you shut down and restart the instance (with 
STARTUP NOMOUNT) after removing an unwanted SPFILE. See 
"Managing Initialization Parameters Using a Ser\'er Parameter File" on 
page 2-31 for more information. 
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See Also: 



■ "Specifying Oracle-Managed Files at Database Creation" on 
page 2-18 

■ Chapter 15, "Using Oracle-Managed Files" 

. "Understanding the CREATE DATABASE Statement" on 
page 2-14 

■ Oracle Database SQL Language Reference for more information 
about specifying the clauses and parameter values for the 

CREATE DATABASE statement 

step 10: Create Additional Tablespaces 

To make the database functional, you need to create additional tablespaces for vour 
application data. The following sample script creates some additional tablespaces: 

OtEATE TABLESPACE appsjbs LOGGIHG 

DATaFILE '/uOl/app/oracle/oradata/raynewdb/appsOl.dbf 

SIZE 500M REUSE AUTOEXTEND OH HEXT 1280K MAXSIZE nMLIMITED 

EXTENT MAHAGEHENT LOCAL; 

— create a talilespace for indexes, separate from user tablespace (optional) 

OffiATE TABLESPACE indx_tbs LOGGING 

DATAFII^ 7u01/app/oracle/oradata/mynewdb/indx01.dbf ' 

SIZE lOOM REUSE AUTOEXTEND OH HEXT 1280K MAXSIZE UHLIMITED 

EXTENT MANAGEMENT LOCAL; 

For information about creating tablespaces, see Chapter 12, "Managing Tablespaces". 

Step 11: Run Scripts to Build Data Dictionary Views 

Run the scripts necessarv" to build data dictionary views, synonyms, and PL/SQL 
packages, and to support proper functioning of SQLTlus: 

@? /rdbrns/ admin/ catalog.sql 
@?/rdbiiis/admin/catproc .sql 
@?/sglplus/adirLin/pupbld.sql 
EXIT 

The at-sign (@) is shorthand for the command that runs a SQL*Plus script. The 
question mark (?) is a SQL*Plus variable indicating the Oracle home directory. The 
following table contains descriptions of the scripts: 

Script Description 

CATALOG . SQL Creates the views of the data dictionary tables, the dynamic 

performance views, and public synonyms for many of the views. 
Grants PUBLIC access to the E\'nonyms. 

CATPROC.SQL Runs all scripts required for or used with PL /SQL. 

PUPBLD .SQL Required for SQL'Plus. Enables SQL 'Plus to disable commands by 

user. 

Step 1 2: Run Scripts to Install Additional Options (Optional) 

You mav want to run other scripts. The scripts that you run are determined bv the 
features and options you choose to use or install. Many of the scripts available to vou 
are described in the Oracle Database Reference. 
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If voLi plan to install other Oracle products to work with this database, see the 
installation instructions for those products. Some products require you to create 
additional data dictionary tables. Usually, command files are provided to create and 
load these tables into the database data dictionary. 

See your Oracle documentation for the specific products that you plan to install for 
instaUation and administration instructions. 

Step 13: Back Up the Database. 

Take a full backup of the database to ensure that you have a complete set of files from 
which to recover if a media failure occurs. For information on backing up a database, 
see Oracle Database Backup and Recoveiy User's Guide. 

Step 14: (Optional) Enable Automatic Instance Startup 

You might want to configure the Oracle instance to start automatically when its host 
computer restarts. See your operating system documentation for instructions. For 
example, on Windows, use the following command to configure the database service 
to start the instance upon computer restart: 

OEADIM -EDIT -SID sid -STARTMODE ADTO -SRVCSTAET SYSTEM [-SPFILE] 

You must use the -SPFILE argument if you want the instance to read an SPFILE upon 
automatic restart. 

See the section "Using ORADIM to Administer an Oracle Database Instance" in Oracle 
Daiabaie Platform Guide for Microsoft Windows for more information on the ORADIM 
command. 

Understanding the CREATE DATABASE Statement 

When you execute a CREATE DATABASE statement, Oracle Database performs a 
number of operations. The actual operations performed depend on the clauses that 
you specify in the CREATE DATABASE statement and the initialization parameters that 
you have set, Oracle Database performs at least these operations: 

Creates the data files for the database 

Creates the control files for the database 

Creates the redo log files for the database and establishes the ARCHIVELOG mode. 

Creates tlie SYSTEM tablespace 

Creates the SYSAUX tablespace 

Creates the data dictionary 

Sets the character set that stores data in the database 

Sets the database time zone 

Mounts and opens the database for use 

This section discusses several of the clauses of the CREATE DATABASE statement. It 
expands upon some of the clauses discussed in "Step 9: Issue the CREATE DATABASE 
Statement" on page 2-9 and introduces additional ones. Many of the CREATE 
DATABASES clauses discussed here can be used to simplify tlie creation and 
management of your database. 

The following topics are contained in this section: 
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Protecting Your Database: Speciiying Passwords for Users SYS and SYSTEM 

Creating a Locallv Managed SYSTEM Tablespace 

About the SYSAUX Tablespace 

Using Automatic Undo Management: Creating an Undo Tablespace 

Creating a Default Temporary Tablespace 

Specifying Oracle-Managed Files at Database Creation 

Supporting Bigfile Tablespaces During Database Creation 

Specifying the Database Time Zone and Time Zone File 

Specifying FORCE LOGGING Mode 

Protecting Your Database: Specifying Passwords for Users SYS and SYSTEM 

The clauses of the CREATE DATABASE statement used for specifying the passwords for 
users SYS and SYSTEM are: 

■ USER SYS IDENTIFIED BY pas sword 

■ USER SYSTEM IDENTIFIED BY password 

If you omit these clauses, these users are assigned the default passwords 
change_on_in stall and manager, respectively. A record is written to the alert log 
indicating that the default passwords were used. To protect your database, vou must 
change these passwords using the ALTER USER statement immediately after database 
creation. 

Oracle strongly recommends that you specify these clauses, even though they are 
optional in this release of Oracle Database. The default passwords are commonlv 
known, and if you neglect to change them later, you leave database vulnerable to 
attack by mahcious users. 

When choosing a password, keep in mind that beginning in Release llg, passwords 
are case sensitive. Also, there mav be password formatting requirements for your 
database. See the section entitled "How Oracle Database Checks the Complexity of 
Passwords" in Oracle Database Seairily Guide for more information. 

See Also: "Some Security Considerations" on page 2-43 

Creating a Locally lUlanaged SYSTEI\/I Tablespace 

Specify the EXTENT MANAGEMENT LOCAL clause in the CREATE DATABASE statement 
to create a locally managed SYSTEM tablespace. The COMPATIBLE initiahzation 
parameter must be set to 10.0.0 or higher for this statement to be successful. If you do 
not specify the EXTENT MANAGEMENT LOCAL clause, by default the database creates a 
dictionar}' -managed SYSTEM tablespace. Dictionary-managed tablespaces are 
deprecated. 

If you create your database with a locally managed SYSTEM tablespace, and if you are 
not using Oracle-managed files, ensure that the following conditions are met: 

■ You specify the DEFAULT TEMPORARY TABLESPACE clause in the CREATE 
DATABASE statement, 

■ You include the UNDO TABLESPACE clause in the CREATE DATABASE statement. 
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See Also: 



Orack' Database SQL Language Reference for more specific 
information about the use of the DEFAULT TEMPORARY 

TABLESPACE and UNDO TABLESPACE clauses when EXTENT 

MANAGEMENT LOCAL is specified for the SYSTEM tablespace 

"Locally Managed Tablespaces" on page 12-3 

"Migrating the SYSTEM Tablespace to a Locally Managed 
Tablespace" on page 12-29 



About the SYSAUX Tablespace 



The SYSAUX tablespace is always created at database creation. The SYSAUX tablespace 
serves as an auxiliarv tablespace to the SYSTEM tablespace. Because it is the default 
tablespace for nianv Oracle Database features and products that previously required 
their own tablespaces. it reduces the number of tablespaces required by the database. 
It also reduces the load on the SYSTEM tablespace. 

You can specifv only datafUe attributes for the SYSAUX tablespace, using the SYSAUX 
DATAFILE clause in the CREATE DATABASE statement. Mandatory attributes of the 
SYSAUX tablespace are set by Oracle Database and include: 

■ PERMANENT 

■ READ WRITE 

■ EXTENT MANAGMENT LOCAL 

■ SEGMENT SPACE MANAGMENT AUTO 

You cannot alter these attributes with an ALTER TABLESPACE statement, and any 
attempt to do so will result in an error. You cannot drop or rename the SYSAUX 
tablespace. 

The size of the SYSAUX tablespace is determined by the size of the database 
components that occupy SYSAUX, See Table 2-2 for a list of alt SYSAUX occupants. 
Based on the initial sizes of these components, the SYSAUX tablespace needs to be at 
least 240 MB at the time of database creation. The space requirements of the SYSAUX 
tablespace will increase after the database is fullv deploved, depending on the nature 
of its use and workload. For more information on how to manage the space 
consumption of the SYSAUX tablespace on an ongoing basis, please refer to the 
"Managing the SYSAUX Tablespace" on page 12-25, 

If you include a DATAFILE clause for the SYSTEM tablespace, then vou must specify 
the SYSAUX DATAFILE clause as well, or the CREATE DATABASE statement will fail. 
This requirement does not exist if the Oracle-managed files feature is enabled (see 
"Specifying Oracle-Managed Files at Database Creation" on page 2-18), 

The SYSAUX tablespace has the same security attributes as the SYSTEM tablespace. 

Note: This documentation discusses the creation of the SYSAUX 
database at database creation. When upgrading from a release of 
Oracle Database that did not require the SYSAUX tablespace, you 
must create the SYSAUX tablespace as part of the upgrade process. 
This is discussed in Orack Database Upgrade Guide. 
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Table 2-2 lists the components that use the SYSAUX tablespace as their default 
lablespace during installation, and the tablespace in which they were stored in earlier 
releases: 

Table 2-2 Database Components and the SYSAUX Tablespace 



Component Using SYSAUX 



Tablespace in Earlier Releases 



Analytical Workspat^e Objet?t Table 

Enterprise Manager Repository 

LogMiner 

Logical Standby 

OLAP API History Tables 

Oracle Data Mining 

Oracle Spatial 

Oracle Streams 

Oracle Text 

Oracle Ultra Search 

Oracle mfcrMedia ORDPLUGIHS Components 

Oracle iiiterMedis ORDSYS Components 

Oracle mterMedia SI_IHFORMTN_SCHEMA 
Components 

Server Manageability Components 

Statspack Repository 

Oracle Scheduler 

Workspace Manager 



SYSTEM 

0EM_REP0SITORY 

SYSTEM 

SYSTEM 

CWMLITE 

ODH 

SYSTEM 

SYSTEM 

DESYS 

DRSYS 

SYSTEM 

SYSTEM 

SYSTEM 



User-defined 



SYSTEM 



See Also: "Managing the SYSAUX Tablespace" on page 12-25 for 
information about managing the SYSAUX tablespace 

Using Automatic Undo Management: Creating an Undo Tablespace 

Automatic undo management uses an undo tablespace. To enable automatic undo 
management, set the UNDO_MANAGEMENT initialization parameter to AUTO in vour 
initialization parameter file. Or, omit this parameter, and the database defaults to 
automatic undo management. In this mode, undo data is stored in an undo tablespace 
and is managed bv Oracle Database. If you want to define and name the undo 
tablespace yourself, you must include the UNDO TABLESPACE clause in the CREATE 
DATABASE statement at database creation time. If you omit this clause, and automatic 
undo management is enabled, the database creates a default undo tablespace named 

SYS_UNDOTBS. 

See Also: 

■ "Specifying the Method of Undo Space Management" on 
page 2-28 

■ Chapter 14, "Managing Undo", for information about the 
creation and use of undo tabiespaces 
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Creating a Default Permanent Tablespace 

The DEFAULT TABLESPACE clause of the CREATE DATABASE statement specifies a 
default permanent tablespace for the database. Oracle Database assigns to this 
tablespace anv non-SYSTEM users for whom vou do not explicitly specif;' a different 
permanent tablespace. If you do not specify this clause, then the SYSTEM tablespace is 
the default permanent tablespace for non-SYSTEM users. Oracle strongly recommends 
that you create a default permanent tablespace. 

See Also: Oracle Database SQL Language Refcrciia: for the syntax of 

the DEFAULT TABLESPACE clause of CREATE DATABASE and 
ALTER DATABASE 

Creating a Default Temporary Tablespace 

The DEFAULT TEMPORARY TABLESPACE clause of the CREATE DATABASE statement 

creates a default temporary tablespace for the database. Oracle Database assigns this 
tablespace as the temporary tablespace for users who are not explicitly assigned a 
temporary tablespace. 

You can exphcitly assign a temporary' tablespace or tablespace group to a user in the 
CREATE USER statement, Howeyer, if you do not do so, and if no default temporary 
tablespace has been specified for the database, then by default these users are assigned 
the SYSTEM tablespace as their temporary tablespace. It is not good practice to store 
temporary data in the SYSTEM tablespace, and it is cumbersome to assign eyery user a 
temporary tablespace individually. Therefore, Oracle recommends that you use the 

DEFAULT TEMPORARY TABLESPACE clause of CREATE DATABASE. 



Note: When you specify a locally managed SYSTEM tablespace, 
the SYSTEM tablespace caniioS be used as a temporary tablespace. In 
this case you must create a default temporary tablespace. This 
behayior is explained in "Creating a Locally Managed SYSTEM 
Tablespace" on page 2-15. 



See Also: 

■ Oracle Database SQL Language Reference for the syntax of the 

DEFAULT TEMPORARY TABLESPACE clause of CREATE 
DATABASE and ALTER DATABASE 

■ "Temporary Tablespaces" on page 12-10 for information about 
creating and using temporary tablespaces 

■ "Multiple Temporar\" Tablespaces: Using Tablespace Groups" 
on page 12-12 for information about creating and using 
temporary tablespace groups 

Specifying Oracle-Managed Files at Database Creation 

You can minimize the number of clauses and parameters that you specify in your 
CREATE DATABASE statement by using the Oracle-managed files feature. You do this 
by specifying either a director;' or Automatic Storage Management (ASM) disk group 
in which your files are created and managed by Oracle Database. 

By including any of the initialization parameters DB_CREATE_FILE_DEST , 

DB_CREATE_ONLIKE_LOG_DEST_ii, or DB_RECOVERY_FILE_DEST in your 

initialization parameter file, you instruct Oracle Database to create and manage the 
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underlying operating system files of your database. Oracle Database will 
automatically create and manage the operating system files for the following database 
structures, depending on which initialization parameters vou specify and how you 
specify clauses in your CREATE DATABASE statement: 

Tablespaces and their datafiles 

Temporary tablespaces and their tempfiles 

Control fUes 

Redo log files 

Archived redo log files 

Flashback logs 

Block change tracking files 

RMAN backups 

See Also: "Specifying a Flash Recoyen' Area" on page 2-26 for 
information about setting initialization parameters that create a 
flash recovery area 

The following CREATE DATABASE statement shows briefly how the Oracle-managed 
files feature works, assuming vou have specified required initialization parameters: 

CREATE DATABASE mynewdb 

USER SYS IDENTIFIED BY sys_pdssword 

USER SYSTEM IDENTIFIED BY systein_^assword 

EXTENT MANAGEMENT LOCAL 

UHDO TABLESPACE undotbs 

DEFAULT TEMPORARY TABLESPACE teraptsl 

DEFAULT TABLESPACE users; 

■ The SYSTEM tablespace is created as a locally managed tablespace. Without the 
EXTENT MANAGEMENT LOCAL clause, the SYSTEM tablespace is created as 
dictionary managed, which is not recommended, 

■ No DATAFILE clause is specified, so the database creates an Oracle-managed 
datafile for the SYSTEM tablespace. 

■ No LOGFILE clauses are included, so the database creates two Oracle-managed 
redo log file groups. 

■ No SYSAUX DATAFILE is included, so the database creates an Oracle-managed 
datafUe for the SYSAUX tablespace. 

■ No DATAFILE subclause is specified for the UNDO TABLESPACE and DEFAULT 
TABLESPACE clauses, so the database creates an Oracle-managed datafile for each 
of these tablespaces. 

■ No TEMPFILE subclause is specified for the DEFAULT TEMPORARY TABLESPACE 
clause, so the database creates an Oracle-managed tempfile. 

■ If no CONTROL_FILES initialization parameter is specified in the initialization 
parameter file, then the database also creates an Oracle-managed control file. 

■ If you are using a server parameter file (see "Managing Initialization Parameters 
Using a Server Parameter File" on page 2-31), the database automatically sets the 
appropriate initialization parameters. 
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See Also: 

■ Chapter 15, "Using Oracle-Managed Files", for information 
about the Oracle-managed files feature and how to use it 

■ Oracle Database Storage Administrator's Guide, for information 
about Automatic Storage Management 

Supporting Bigfile Tablespaces During Database Creation 

Oracle Database simphfies m<inagement of tablespaces and enables support for 
ultra-large datab.ises bv letting vou create bigfile tablespaces. Bigfile t.iblespaces can 
contain only one file, but that file can have up to 4G blocks. The maximum number of 
datafiles in an Oracle Database is limited (usually to 64K files). Therefore, bigfile 
tablespaces can significantly enhance the storage capacit\' of an Oracle Database. 

This section discusses the clauses of the CREATE DATABASE statement that let you 
include support for bigfile tablespaces. 

See Also: "Bigfile Tablespaces" on page 12-6 for more information 
about bigfile tablespaces 

Specifying tlie Default Tablespace Type 

The SET DEFAULT. . .TABLESPACE clause of the CREATE DATABASE statement to 
determines the default t\'pe of tablespace for this database in subsequent CREATE 
TABLESPACE statements. Specify either SET DEFAULT BIGFILE TABLESPACE or 
SET DEFAULT 3MALLFILE TABLESPACE. If you omit this clause, the default is a 
smallfile tablespace, which is the traditional type of Oracle Database tablespace. A 
smallfile tablespace can contain up to 1022 files with up to 4M blocks each. 

The use of bigfile tablespaces further enhances the Oracle-managed files feature, 
because bigfile tablespaces make datafiles completely transparent for users. SQL 
Bvntax for the ALTER TABLESPACE statement has been extended to allow you to 
perform operations on tablespaces, rather than the underlving datafiles. 

The CREATE DATABASE statement shown in "Specif\-ing Oracle- Managed Files at 
Database Creation" on page 2-18 can be modified as follows to specify that the default 
type of tablespace is a bigfile tablespace: 

CREaTE DATABASE mynewdb 

USER SYS IDENTIFIED BY sys_password 

USER SYSTEM IDENTIFIED BY systeia_password 

SET DEFAULT BIGFILE TABLESPACE 

UHDO TABLESPACE undotbs 

DEFAULT TEMPORARY TABLESPACE temptsl; 

To dynamically change the default tablespace type after database creation, use the SET 
DEFAULT TABLESPACE clause of the ALTER DATABASE statement: 

ALTER DATABASE SET DEFAULT BIGFILE TABLESPACE; 

You can determine the current default tablespace tvpe for the database by querying 
the DATABASE_PROPERTIES data dictionary view as follows: 

SELECT PROPERTY_VALUE FROM DATABASE_PROPERTIES 
WHERE PROPERTY NAME = ' DEFAULT TBS TYPE ' ; 
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Overriding the Default Tablespace Type 

The SYSTEM and SYSAUX tablespaces are always created with the default tablespace 
tj'pe. However, you can explicitly override the default tablespace type for the UNDO 
and DEFAULT TEMPORARY tablespace during the CREATE DATABASE operation. 

For example, you can create a bigfile UNDO tablespace in a database with the default 
tablespace tvpe of smallfile as follows: 

CREATE DATABASE mynewdb 

BIGFILE nUDO TABLESPACE undotbs 

DATAFILE ' /u01/oracle/oradata/myriewdb/-undotbs01 .dbf ' 
SIZE 200M REUSE AUTOEXTEND OH MMSIZE UNLIMITED; 

You can create a smallfile DEFAULT TEMPORARY tablespace in a database with the 
default tablespace type of bigfile as follows: 

CREATE DATABASE mynewdb 

SET DEFAULT BIGFILE TABLSPACE 

SMALLFILE DEFAULT TEMPORARY TABLESPACE temptsl 

TEMPFILE '/uOl/oracle/oradata/mynewdb/terapOl.dbf ' 
SIZE 2 0M REUSE 



Specifying the Database Time Zone and Time Zone File 

You can specify the database time zone and the supporting time zone file. 

Setting the Database Time Zone 

Set the database time zone when the database is created by using the SET TIME_ZONE 
clause of the CREATE DATABASE statement. If you do not set the database time zone, 
then it defaults to the time zone of the server's operating svstem. 

You can change the database time zone for a session by using the SET TIME_ZONE 
clause of the ALTER SESSION statement. 

See Also: Oracle Database Gbbalizalion Support Guide for more 
information about setting the database time zone 

Specifying the Database Time Zone File 

Tw^o time zone files are included in the Oracle home directorv. The default time zone 

file is SORACLE_HOME/oracore/ zone info/ timezonelrg . dat. A smaller time 
zone file can be found in SORACLE_H:OME/oracore/ zoneinf o/ timezone .dat. 

If you are already using the smaller time zone file and vou want to continue to use it in 
an Oracle Database 11"^ environment or if you want to use the smaller time zone file 
instead of the default time zone file, then complete the following tasks: 

1. Shut down the database, 

2. Set the ORA_TZFILE environment variable to the full path name of the 

timezone .dat file. 

3. Restart the database. 

If vou are already using the default time zone file, then it is not practical to change to 
the smaller time zone file because the database may contain data with time zones that 
are not part of the smaller time file. 
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All databases that share information must use the same time zone data file. 

The time zone files contain the valid time zone names. The following information is 
also included for each time zone: 

■ Offset from Coordinated Universal Time (UTC) 

■ Transition times for Daylight Saving Time 

■ Abbreviations for standard time and Daylight Saving Time 

To view the time zone names in the file being used by your database, use the following 
query: 

SELECT ' FROM VSTIHEZONE_MMES,- 

Specifying FORCE LOGGING Mode 

Some data definition language statements (such as CREATE TABLE) allow the 
NOLOGGING clause, which causes some database operations not to generate redo 
records in the database redo log. The NOLOGGING setting can speed up operations that 
can be easily recovered outside of the database recoverv mechanisms, but it can 
negativelv affect media recoverv and standby databases. 

Oracle Database lets you force the writing of redo records even when NOLOGGING 
has been specified in DDL statements. The database never generates redo records for 
temporary tablespaces and temporary segments, so forced logging has no affect for 
objects. 

See Also: Oracle Database SQL Language Reference for information 
about operations that can be done in NOLOGGING mode 

Using the FORCE LOGGING Clause 

To put the database into FORCE LOGGING mode, use the FORCE LOGGING clause in 
the CREATE DATABASE statement. If you do not specify this clause, the database is not 
placed into FORCE LOGGING mode. 

Use the ALTER DATABASE statement to place the database into FORCE LOGGING 
mode after database creation. This statement can take a considerable time for 
completion, because it waits for all unlogged direct writes to complete. 

You can cancel FORCE LOGGING mode using the following SQL statement: 

ALTER DATABASE NO FORCE LOGGING; 

Independent of specifying FORCE LOGGING for the database, you can selectively 
specify FORCE LOGGINGorWO FORCE LOGGING at the tablespace level However, if 
FORCE LOGGING mode is in effect for the database, it takes precedence over the 
tablespace setting. If it is not in effect for the database, then the individual tablespace 
settings are enforced. Oracle recommends that either the entire database is placed into 
FORCE LOGGING mode, or individual tablespaces be placed into FORCE LOGGING 
mode, but not both. 

The FORCE LOGGING mode is a persistent attribute of the database. That is, if the 
database is shut down and restarted, it remains in the same logging mode. However, if 
you re-create the control file, the database is not restarted in the FORCE LOGGING 
mode unless you specify the FORCE LOGGING clause in the CREATE CONTROL FILE 
statement. 
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See Also: "Controlling the Writing of Redo Records" on 

page 12-14 for information about using the FORCE LOGGING clause 

for tablespace creation. 

Performance Considerations of FORCE LOGGING lUlode 

FORCE LOGGING mode results in some performance degradation. If the primary 
reason for specifying FORCE LOGGING is to ensure complete media recovery, and 
there is no standby database active, then consider the following: 

■ How many media failures are likely to happen? 

■ How serious is the damage if unlogged direct writes cannot be recovered? 

■ Is the performance degradation caused by forced logging tolerable? 

If the database is running in NOARCHIVELOG mode, then generally there is no benefit 
to placing the database in FORCE LOGGING mode. Media recovery is not possible in 
NOARCHIVELOG mode, SO if you combine it with FORCE LOGGING, the result may be 
performance degradation with little benefit. 

Understanding Initialization Parameters 

When an Oracle instance starts, it reads initialization parameters from an initialization 
parameter file. For any initialization parameters not specifically included in the 
initialization param.eter file, the database supplies defaults. 

The initialization parameter file can be either a read-only text file, or a read/write 
binary file. The binary file is called a server parameter file. A server parameter file 
enables you to change initialization parameters with ALTER SYSTEM commands and 
to persist the changes across a shutdown and startup. It also provides a basis for 
self-tuning bv Oracle Database. For these reasons, it is recommended that vou use a 
server parameter file. You can create one manually from your edited text initialization 
file, or automatically by using Database Configuration Assistant (DBCA) to create 
your database. 

Before you manually create a server parameter file, you can start an instance with a 
text initialization parameter file. Upon startup, the Oracle instance first searches for a 
server parameter file in a default location, and if it does not find one, searches for a 
text initialization parameter file. You can also override an existing server parameter 
file bv naming a text initialization parameter file as an argument of the STARTUP 
command. 

Default file names and locations for the text initialization parameter file are shown in 
the following table: 



Platform 


Default Name 


Default Location 


UNIX 

and 

Linux 


i n i t ORACLE_SID. o r a 

For example, the 
initialization parameter file 
for the mynewdb database 
is named: 

ini tMiiynewdb . ora 


ORACfF HOME/6hs 


Windows 


initORACLE_SID. ora 


ORACfF HOME\database 
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For more information on server parameter files, see "Managing Initialization 
Parameters Using a Ser\'er Parameter File" on page 2-31. For more information on the 
STARTUP command, see "Understanding Initialization Parameter Files" on page 3-2. 

Sample Initialization Parameter File 

Oracle Database provides generally appropriate values in a sample text initialization 
parameter file. You can edit these Oracle-supplied initialization parameters and add 
others, depending upon your configuration and options and how voii plan to tune the 
database. 

The sample text initialization parameter file is named init.ora and is found in the 
follovi'ing location on most platforms: 

ORACLE_HOME/ dhs 

The following is the content of the sample file: 

### S l# tt tt S# tt tt t# tt tt l# tt l# titt ###*!##### lit l# It l## #11 tt It lit#l*#l*«HHit##*«ll«Htlit#l#«IHt lit 

# Example IHIT.OEA file 
# 

# This file is provided by Oracle Corporation bo help you start by providing 
t a starting point to customize your EDBMS installation for your site. 

# 

I HOIE: The values tiiat are used in this file are only intended to be used 

I as a starting point. You may want to adjust/tune those values to your 

# specific hardware and needs. You may also consider using Database 

# Configuration Assistant tool {DBCA} to create INIT file and to size your 
t initial set of tablespaces based on the user input. 
###ttt#ttttt#itt##ttttt#ttt#fttt##ttttt#tttt#ttttttt#ttt#fttt##ttttt#ttttlttttt#ttttl#ttttt#tttt#tttttt#ttttt#ttttt#l 

# Change ' <ORACLE_BASEj- ' to point to the oracle base {the one you specify at 

# install time) 

db_name= ' ORCL ' 

memory_target= IG 

processes = 150 

audit_file_dest='<ORACLE_BASE>/admin/orcl/adump' 

audit_trail ='db' 

dl>_block_s ize= 8192 

dl>_domain= ' ' 

dl>_recovery_file_dest= ' <ORACLE_BASE>/f lash_recovery_area ' 

dl>_r ec o very_f i le_des t_s i z e= 2 G 

diagnoEtic_dest= ' ■:OEACI£_BASE> ' 

dispatchers= ' (PR0TOC0L=TCP) (SERVICE=ORCLXDB) ' 

open_c ursors=300 

remote_login_j)asswordfile= 'EXCLUSIVE' 

undo_tablespace= ' UNDOTBSl ' 

I You may want to ensure that control files are created on separate physical 

I devices 

control_f iles = { or a_con troll, Dra_control2 ) 

compatible ='11.1.0' 

If you are creating an Oiacle Database for the first time, Oracle suggests that you 
minimize the number of parameter values that vou alter. As vou become more familiar 
with vour database and environment, vou can dynamicallv tune manv initialization 
parameters using the ALTER SYSTEM statement. If you are using a text initialization 
parameter file, vour changes are effective only for the current instance. To make them 
permanent, you must update them manually in the initialization parameter file, or 
they will be lost over the next shutdown and startup of the database. If you are using a 
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server parameter file, initialization parameter file changes made hv the ALTER 
SYSTEM statement can persist across shutdown and startup. This is discussed in 
"Managing Initialization Parameters Using a Server Parameter File". 

This section introduces you to some of the basic initialization parameters vou can add 
or edit before you create vour new database. 

The following topics are contained in this section: 

Determining the Global Database Name 

Specifying a Flash Recoverv Area 

Specifying Control Files 

Specif\'ing Database Block Sizes 

Specif\'ing the Maximum Number of Processes 

Specifying the DDL Lock Timeout 

Specifying the Method of Undo Space Management 

AboutThe COMPATIBLE Initialization Parameter 

Setting the License Parameter 

See Also: 

■ Oracle Database Reference for descriptions of all initialization 
parameters including their default settings 

■ Chapter 5, "Managing Memory" for a discussion of the 
initialization parameters that pertain to memory management 



Determining the Global Database Name 



The global database name consists of the user-specified local database name and the 
location of the database within a network structure. The DB_NaME initialization 
parameter determines the local name component of the database name, and the 
DB_DOMAIW parameter, which is optional, indicates the domain (logical location) 
within a netvvork structure. The combination of the settings for these tivo parameters 
must form a database name that is unique within a network. 

For example, to create a database with a global database name of 

test .us . acme . com, edit the parameters of tlie new parameter file as follows: 

DB_NME = test 
DB_DOMAIH = us.acme.com 

You can rename the GLOBAL_NaME of your database using the ALTER DATABASE 
RENAME GLOBAL_ISIAME statement. However, vou must also shut down and restart the 
database after first changing the DB_HAME and DB_DOMAIW initialization parameters 
and recreating the control files. Recreating the control files is easily accomplished with 
the command ALTER DATABASE BACKUP CONTROLFILE TO TRACE. See Orack 
Daiabase Backup and Recovery User's Guide for more information. 



See Also: Oracle Database Utilities for information about using the 
DBWEWID utilit)', which is another means of changing a database 
name 
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DB_NAME Initialization Parameter 

DB_NAME must be set to a text string of i\o more than eight characters. During database 
creation, the name provided for DB_NflME is recorded in the datafiles, redo log files, 
and control file of the database. If during database instance startup the value of the 
DB_NAME parameter (in the parameter file) and the database name in the control file 
are not the same, the database does not start. 

DB_DOMAIN Initialization Parameter 

DB_DOMAIW is a text string that specifies the network domain where the database is 
created. If the database vou are about to create will ever be part of a distributed 
database svstem, give special attention to this initialization parameter before database 
creation. This parameter is optional. 

See Also: Part V, "Distributed Database Management" for more 
information about distributed databases 

Specifying a Flash Recovery Area 

A flash recovery' area is a location in which Oracle Database can store and manage files 
related to backup and recoverv. It is distinct from the database area, which is a 
location for the current database files (datafiles, control files, and online redo logs). 

You specify a flash recovery area with the following initialization parameters: 

■ DB_RECOVEEY_FILE_DEST: Location of the flash recovery area. This can be a 
director}', file system, or Automatic Storage Management (ASM) disk group. It 
cannot be a raw file system. 

In an Oracle Real Application Clusters (RAC) environment, this location must be 
on a cluster file svstem, ASM disk group, or a shared directorv configured through 

NFS. 

■ DB_RECOVERY_FILE_DEST_SI ZE: Specifies the maximum total bytes to be used 
by the flash recover}' area. This initialization parameter must be specified before 

DB_EECOVEEY_FILE_DEST is enabled. 

In an Oracle RAC environment, the settings for these two parameters must be the 
same on all instances. 

You cannot enable these parameters if vou have set values for the 
LOG_AECHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST parameters. You must 
disable those parameters before setting up the flash recoverv area. You can instead set 
values for the LOG_ARCHIVE_DEST_n parameters. If vou do not set values for local 
LOG_ARC;HIVE_DEST_n, then setting up the flash recovery area will implicitly set 
LOG_ARCHIVE_DEST_10 to the flash recover}'" area, 

Oracle recommends using a flash recovery area, because it can simplify backup and 
recoverv operations for your database. 

See Also: Oracle Database Backup and Recovery User's Guide to 
learn how to create and use a flash recoverv area 

Specifying Control Files 

The CGNTRGL_FILES initialization parameter specifies one or more control filenames 
for the database. When you execute the CREATE DATABASE statement, the control 
files hsted in the C0NTR0L_FILE3 parameter are created. 



2-26 Oracle Database Administrator's Guide 



Understanding Inilialization Parameters 



If you do not include CONTROL_FILES in the initialization par iinieter file, then Oracle 
Database creates a control file in the same directory as the initialization parameter 
file, using a default operating system-dependent filename. If you haye enabled 
Oracle- managed files, the database creates Oracle-managed control files. 

If vou want the database to create new operating system files when creating database 
control files, the filenames listed in the CONTROL_FILES parameter must not match 
any filenames that currently exist on your svstem. If you want the database to reuse or 
oyerwrite existing files when creating database control files, ensure that the filenames 
listed in the CONTR0L_FILES parameter match the filenames that are to be reused, 
and include a CONTROLFILE REUSE clause in the CREATE DATABASE statement. 

Oracle strongly recommends you use at least two control files stored on separate 
physical disk drives for each database. 

See Also: 

■ Chapter 9, "Managing Control Files" 



"Specifying Oracle-Managed Files at Database Creation" on 
page 2-18 



Specifying Database Block Sizes 



The DB_BLOCK_SIZE initialization parameter specifies the standard block size for the 
database. This block size is used for the SYSTEM tablespace and bv default in other 
tiiblespaces. Oracle Database can support up to four additional nonstandard block 



DB_BLOCK_SIZE Initialization Parameter 

The most commonlv used block size should be picked as the standard block size. In 
manv cases, this is the only block size that you need to specify. Typically, 
DB_BLOCK_SIZE is set to either 4K or 8K. If you do not set a value for this parameter, 
the default data block size is operating svstem specific, which is generally adequate. 

You cannot change the block size after database creation except bv re-creating the 
database. If the database block size is different from the operating system block size, 
ensure that the database block size is a multiple of the operating svstem block size. For 
example, if your operating svstem block size is 2K (2048 bytes), the following setting 
for theDB_BLOCK_SIZE initialization parameter is valid: 

DB_BLOCK_S IZE=4 9 6 

A larger data block size provides greater efficiency in disk and memor\' I/O (access 
and storage of data). Therefore, consider specifying a block size larger than your 
operating system block size if the following conditions exist: 

■ Oracle Database is on a large computer system with a large amount of memory 
and fast disk drives. For example, databases controlled bv mainframe computers 
with vast hardware resources typicaUy use a data block size of 4K or greater, 

■ The operating svstem that runs Oracle Database uses a small operating svstem 
block size. For example, if the operating system block size is IK and the default 
data block size matches this, the database may be performing an excessive amount 
of disk I/O during normal operation. For best performance in this case, a database 
block should consist of multiple operating system blocks. 

See Also: Youi operating system specific Oracle documentation 
for details about the default block size. 
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Nonstandard Block Sizes 

Tablespaces of nonstandard block sizes can be created using the CREATE 
TABLE SPACE statement and specifying theBLOCKSIZE clause. These nonstandard 
block sizes can have any of the following power-of-two values: 2K, 4K, 8K, 16K or 32K, 
Platform -specific restrictions regarding the maximum block size apply, so some of 
these sizes may not be allowed on some platforms. 

To use nonstandard block sizes, vou must configure subcaches within the buffer cache 
area of the SG A memorv for all of the nonstandard block sizes that vou intend to use. 
The initialization parameters used for configuring these subcaches are described in 
"Using Automatic Shared Memorv Management" on page 5-7. 

The ability to specify multiple block sizes for your database is especially useful if you 
are transporting tablespaces between databases. You can, for example, transport a 
tablespace that uses a 4K block size from an OLTP environment to a data warehouse 
environment that uses a standard block size of 8K. 

See Also: 

■ "Creating Tablespaces" on page 12-2 

■ "Transporting Tablespaces Between Databases" on page 12-29 

Specifying the Maximum Number of Processes 

The PROCESSES initialization parameter determines the maximum number of 
operating system processes that can be connected to Oracle Database concurrently. 
The value of this parameter must be a minimum of one for each background process 
plus one for each user process. The number of background processes will varv 
according the database features that you are using. For example, if vou are using 
Advanced Queuing or the file mapping feature, you will have additional background 
processes. If you are using Automatic Storage Management, then add three 
additional processes for the database instance. 

If you plan on running 50 user processes, a good estimate would be to set the 
PROCESSES initialization parameter to 70. 

Specifying tiie DDL Locit Timeout 

Data Definition Language (DDL) statements require exclusive locks on internal 
structures. If these locks are unavailable when a DDL statement runs, the DDL 
statement fails, though it might have succeeded if it had been executed subseconds 
later. 

To enable DDL statements to wait for locks, specify a DDL lock timeout — the number 
of seconds a DDL command waits for its required locks before failing. 

To specify a DDL lock timeout, use the DDL_LOCK_TIMEOUT parameter. The 
permissible range of values for DDL_LOCK_TIMEOUT is to 100.000. The default is 0, 

You can set DDL_LOCK_TIME0UT at the svstem level, or at the session level with an 

ALTER SESSION statement. 

Specifying tlie IVIetliod of Undo Space Management 

Every Oracle Database must have a method of maintaining information that is used 
to undo changes to the database. Such information consists of records of the actions of 
transactions, primarily before they are committed. Collectively these records are called 
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undo data. This section provides instructions for setting up an environment for 
automatic undo management using an undo tablespace. 

See Also: Chapter 14, "Managing Undo" 

UNDO_MANAGEMENT Initialization Parameter 

The UNDO_MANAGEMENT initialization parameter determines whether or not an 
instance starts in automatic undo management mode, which stores undo in an undo 
tablespace. Set this parameter to AUTO to enable automatic undo management mode. 
Beginning with Release 11^, AUTO is the default if the parameter is omitted or is null. 

UNDO_TABLESPACE Initialization Parameter 

When an instance starts up in automatic undo management mode, it attempts to select 
an undo tablespace for storage of undo data. If the database was created in automatic 
undo management mode, then the default undo tablespace (either the system-created 
SYS_UNI10TBS tablespace or the user-specified undo tablespace) is the undo 
tablespace used at instance startup. You can override this default for the instance by 
specifving a value for the UNDO_TABLE SPACE initialization parameter. This parameter 
is especially useful for assigning a particular undo tablespace to an instance in an 
Oracle Real Application Clusters environment. 

If no undo tablespace is specified by the UNDO_TaBLE SPACE initialization parameter, 
then the first available undo tablespace in the database is chosen. If no undo 
tablespace is available, then the instance starts without an undo tablespace, and undo 
data is written to the SYSTEM tablespace. You should avoid running in this mode. 

Note: When using the CREATE DATABASE statement to create a 
database, do not include an UNDO_TABLE SPACE parameter in the 
initialization parameter file. Instead, include an UNDO TABLESPACE 
clause in the CREATE DATABASE statement, 

AboutThe COMPATIBLE Initialization Parameter 

The COMPATIBLE initialization parameter enables or disables the use of features in the 
database that affect file format on disk. For example, if vou create an Oracle Database 
11^^ Release 1 (11.1) database, but specify COMPATIBLE = 10 . . in the initialization 
parameter file, then features that requires 11.1 compatibilitv generate an error if vou 
trv to use them. Such a database is said to be at the 10,0,0 compatibility level. 

You can advance the compatibilit}" level of your database. If vou do advance the 
compatibility of vour database with the COMPATIBLE initialization parameter, there is 
no wav to start the database using a lower compatibility level setting, except bv doing 
a point-in-time reco\'erv to a time before the compatibilitv was ad\'anced. 

The default value for the COMPATIBLE parameter is the release number of the most 
recent major release. 



Note: For Oracle Database 1 Ig Release 1 (11.1), the default 
value of the COMPATIBLE parameter is 11,1.0, The minimum value 
is 10.0.0. If you create an Omcle Database using the default value, 
you can immediatelv use all the new features in this release, and 
you can never downgrade the database. 
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See Also: 



Oracle Database Upgrade Guide for n detailed discussion of 
database compatibility and the COMPATIBLE initialization 
parameter 

Oracle Database Backup and Recover]/ User's G/z/ift: f or infoimation 
about point-in- time recovery of your database 



Setting the License Parameter 



Note: Oracle no longer offers licensing bv the number of 
concurrent sessions. Therefore the LICENSE_MAX_SESSIOWS and 
LICEWSE_SESSIOWS_WAEWIWG initialization parameters are no 
longer needed and have been deprecated. 

If vou use named user licensing, Oiacle Database can help you enforce this form of 
licensing. You can set a limit on the number of users created in the database. Once this 
hmit is reached, vou cannot create more users. 

Note: This mechanism assumes that each person accessing the 
database has a unique user name and that no people share a user 
name. Therefore, so that named user licensing can help you ensure 
compliance with your Oracle license agreement, do not allow 
multiple users to log in using the same user name. 

To limit the number of users created in a database, set the LICENSE_MAX_USERS 
initialization parameter in the database initialization parameter file, as shown in the 
followingexample: 

LICENSE MftX USERS = 200 



Troubleshooting Database Creation 



If database creation fails, you can look at the alert log to determine the reason for the 
failure and to determine corrective action. If the database generates an error that 
includes a process number, the required error information may be in the trace file for 
that process. Look for the trace file that contains the process number in the file name. 
The alert log and trace files are discussed in Chapter 8, "Managing Diagnostic Data". 

You must shut dovi'n the instance and delete any files created by the CREATE 
DATABASE statement before you attempt to create it again. 



Dropping a Database 



Dropping a database involves removing its datafiles, redo log files, control files, and 
initialization parameter files. The DROP DATABASE statement deletes all control files 
and all other database files listed in the control file. To use the DROP DATABASE 
statement successfully, all of the following conditions must apply: 

■ The database must be mounted and closed. 

■ The database must be mounted exclusively— not in shared mode. 

■ The database must be mounted as RESTRICTED . 
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An example of this statement is: 

DROP DATABSSE; 

The DROP DATABASE statement has no effect on archived log files, nor does it have 
any effect on copies or backups of the database. It is best to use RMAN to delete such 
files. If the database is on raw disks, the actual raw disk special files are not deleted. 

If vou used the Database Configuration Assistant to create vour database, vou can use 
that tool to delete (drop) vour database and remove tlie files. 

Managing Initialization Parameters Using a Server Parameter File 

Initialization parameters for the Oracle Database have traditionallv been stored in a 
text initialization parameter file. For better manageabilit}", vou can choose to maintain 
initialization parameters in a binarv server parameter file that is persistent across 
database startup and shutdown. This section introduces the server parameter file, and 
explains how to manage initialization parameters using either method of storing the 
parameters. The following topics are contained in this section. 

What Is a Server Parameter File? 

Migrating to a Server Parameter File 

Creating a Server Parameter File 

Storing the Server Parameter File on HARD-Enabled Storage 

The SPFILE Initialization Parameter 

Changing Initialization Parameter Values 

Clearing Initialization Parameter Values 

Exporting the Server Parameter File 

Backing Up the Server Parameter File 

Recovering a Lost or Damaged Server Parameter File 

Viewing Parameter Settings 

What Is a Server Parameter File? 

A server parameter file can be thought of as a repositorv for initialization parameters 
that is maintained on the machine running the Oracle Database server It is, bv design, 
a server-side initialization parameter file. Initialization parameters stored in a server 
parameter file are persistent, in that any changes made to the parameters while an 
instance is running can persist across instance shutdown and startup. This 
arrangement eliminates the need to manually update initialization parameters to make 
persistent anv changes effected by ALTER SYSTEM statements. It also provides a basis 
for self-tuning by the Oracle Database server. 

A server parameter file is initially built from a text initialization parameter file using 
the CREATE SPFILE statement. (It can also be created directly by the Database 
Configuration Assistant) The server parameter file is a binary file that cannot be 
edited using a text editor Oracle Database provides other interfaces for viewing and 
modifying parameter settings in a server parameter file. 
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Caution: Although you can open the binary server parameter file 
with a text editor and view its text, do not manually edit it. Doing so 
will corrupt the file. You will not be able to start vour instance, and 
if the instance is running, it could fail. 



When you issue a STARTUP command with no PFILE clause, the Oracle instance 
searches an operating system-specific default location for a ser\'er parameter file from 
which to read initialization parameter settings. If no ser\'er parameter file is found, the 
instance searches for a text initialization parameter file. If a server parameter file exists 
but you want to override it with settings in a text initialization parameter file, you 
must specify the PFILE clause when issuing the STARTUP command. Instructions for 
starting an instance using a server parameter file are contained in "Starting Up a 
Database" on page 3-1. 



Migrating to a Server Parameter Fiie 



If vou are currentlv using a text initialization parameter file, use the following steps to 
migrate to a server parameter file. 

1. If the initialization parameter file is located on a client machine, transfer the file 
(for example, FTP) from, the chent machine to the server machine. 

Note: If vou are migrating to a server parameter file in an Oracle 
Real Application Clusters environment, vou must combine all of 
your instance- specific initialization parameter files into a single 
initialization parameter fiie. Instructions for doing this and other 
actions unique to using a server parameter file for instances that are 
part of an Oracle Real Application Clusters installation are 
discussed in Oracle Rat! Appliaifion Cliisicrs Adm in isf ration and 
Deployment Guide and in your platform- specific Oracle Real 
Application Clusters Installation Guide. 



2. Create a server parameter file in the default location using the CREATE S PFILE 
FROM PFILE statement. See "Creating a Server Parameter File" on page 2-32 for 
instructions. 

This statement reads the text initialization parameter file to create a server 
parameter file. The database does not have to be started to issue a CREATE 
SPFILE statement, 

3. Start up or restart the instance. 

The instance finds the new SPFILE in the default location and starts up with it. 



Creating a Server Parameter File 



You use the CREATE SPFILE statement to create a server parameter file. You must 
have the SYSDBA or the SYSOPER system privilege to execute this statement 

Note: When vou use the Database Configuration Assistant to create 
a database, it automatically creates a server parameter file for vou. 
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The CREATE SPFILE statement can be executed before or after instance startup. 
However, if tlie instance has been started using a server parameter file, an error is 
raised if vou attempt to re-create tlie same server parameter file that is currently being 
used bv the instance. 

You can create a server parameter file (SPFILE) from an existing text initialization 
parameter file or from memory. Creating the SPFILE from memorv means copying the 
current values of initialization parameters in the running instance to the SPFILE. 

The following example creates a server parameter file from text initialization 
parameter file /uOl/oracle/dbs/init . or a. In this example no SPFILE name is 
specified, so the file is created w^ith the platform- specific default name and location 
shown in Table 2—3 on page 2-33, 

CREATE SPFII£ FROM PFII£= '/uOl/Dracle/dhs/init .ora ' ; 

The next example illustrates creating a server parameter file and supplying a name 
and location, 

CREATE SPFII£=7ii01/oracle/dl)E/teEt_spfile.ora' 

FROM PFILE=7u01/oracle/dbs/test_init.ora' ; 

The next example illustrates creating a sender parameter file in the default location 
from the current values of the initialization parameters in memory, 

CREATE SPFILE FROM MEMORY; 

Whether vou use the default SPFILE name and default location or specify an SPFILE 
name and location, if an SPFILE of the same name already exists in the location, it is 
overwritten without a warning message. 

When you create an SPFILE from a text initialization parameter file, comments 
specified on the same lines as a parameter setting in the initialization parameter file 
are maintained in the SPFILE, All other comments are ignored, 

Oracle recommends that vou allow the database to give the SPFILE the default name 
and store it in the default location. This eases administration of your database. For 
example, the STARTUP command assumes this default location to read the SPFILE, 

Table 2-3 shows the default name and location for both the text initialization 
parameter file (PFILE) and server parameter file (SPFILE) for the UNIX, Linux, and 
Windows platforms. The table assumes that the SPFILE is a file. If it is a raw device, 
the default name could be a logical volume name or partition device name, and the 
default location could differ. 

Table 2-3 PFILE and SPFILE Default Names and Locations on UNIX, Linux, and Windows 

PlaHorm PFILE Default Name SPFILE Default Name Default Location (PFILE and SPFILE) 

UNIX and in±tORACLE_SID.oi:a spf ileORACLE_SID.ora ORACLE_HOME / dbs or the same 
Linux location as the datafiles 

Windows in±tORACLE_S ID. or a s-p±ileORACLE_SID.ora OJMCLE_HOME\ database 
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Note: Upon startup, the instance first searches for an SPFILE named 
spf ileOJi/5CL£'_STD.Qra, and if not found, searches for 
spf ile . ora. Using spf ile . ora. enables all Real Application 
Cluster (RAC) instances to use the same server parameter file. 

If neither SPFILE is found, the instance searches for the text 
initialization parameter file initOJtACL£_SJi:i.ora. 

If you create an SPFILE in a location other than the default location, you must create a 
text initialization parameter file that points to the server parameter file. For more 
information, see "Starting Up a Database" on page 3-1. 

Storing the Server Parameter File on HARD-Enabled Storage 

Starting with Release 11;^, the server parameter file (SPFILE) is in a new format that is 
compliant with the Oracle Hardware Assisted Resilient Data (HARD) initiative. 
HARD defines a comprehensive set of data validation algorithms, implemented at 
both the software and storage hardware levels, to ensure that no corrupt data is 
written to permanent storage. To fully enable HARD protection for the data in vour 
SPFILE, the SPFILE must reside on HARD-enabled storage, and compatibility for your 
database instance must be advanced to at least 11.0.0. 

You can store the HARD-comphant SPFILE on non-HARD-enabled storage. In this 
case, the new SPFILE format supports only ilelccfioH of corrupt SPFILE data. Storing 
the SPFILE on HARD-enabled storage prevenls corrupt data from being written to 
storage in the first place. 

For m.ore information about HARD, and for a list of storage vendors that supply 
HARD-enabled storage svstems, visit: 

http : / /www . oracle . com/ technology/ deploy/ availability/htdocs /HARD 
.html. 

Follow these guidelines for full HARD protection w^hen instaUing or upgrading vour 
Oracle database: 

When Installing or Initially Creating a Release ^^g Database 

When first installing or creating a Release 11;:; database, the COMPATIBLE initialization 
parameter defaults to 11.1.0, so this requirement for a HARD-compliant server 
parameter file (SPFILE) is met. You must then ensure that the SPFILE is stored on 
HARD-enabled storage. To meet this requirement, do one of the following: 

■ For an Oracle Real Application Clusters environment without shared storage, 
when DBCA prompts for the location of the SPFILE, specifv a location on 
HARD-enabled storage. 

■ For a single- instance installation, or for an Oracle Real Application Clusters 
environment with shared storage, complete these steps: 

1. Complete the database installation with Database Configuration Assistant 
(DBCA). 

The SPFILE is created in the default location. See Table 2-3 on page 2-33 for 
information on default locations. 

2. Do one of the following: 

— Using an operating system command, copy the SPFILE to HARD-enabled 
storage. 
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- In SQL'Plus or another interactive environment such as SQL Developer, 
connect to the database as user SYS and then submit the following 
command: 

CREATE SPFII£ = ' spfile.name' FROM MEMOHY; 

where spfilc_iiivuc is a complete path name, including file name, that 
points to HARD-enabled storage. 

3. Do one of the following: 

- Create a text initialization parameter file (PFILE) in the default location 
with the following single entry: 

SPFILE = spfile_name 

where ipfik_nivuc is the complete path to the SPFILE on HARD-enabled 
storage. 

- On the UNIX and Linux platforms, in the default SPFILE location, create a 
symbolic link to the SPFILE on HARD-enabled storage. 

See Table 2-3 for default name and location information for PFILEs and 
SPFILEs, 

4. Shut down the database instance. 

5. Delete the SPFILE in the default location. 

6. Start up the database instance. 

When Upgrading to Release 11 £r from an Earlier Database Release 

When upgrading to Release ll;; from an earlier database release, complete these steps 
to migrate your SPFILE to the HARD-compliant format and to store the SPFILE on 
HARD-enabled storage: 

1. Start SQL'Plus or another interactive query application, log in to the database as 
user SYS or SYSTEM, and then enter the following command: 

ALTER SYSTEM SET COMPATIBLE = '11.1.0' SCOPE = SPFILE; 



WARNING: Advancing the compatibility level to 11.1.0 enables 

Release llg^ features and file formats and has wide repercussions. 
Consult Oracle Database Upgrade Guide before proceeding. 

2. Restart the database instance. 

The database is now at compatibUitv level 11.1,0. 

3. If your SPFILE is not already on HARD-enabled storage, complete the following 
steps: 

a. In SQL'Plus or another interactive environment, connect to the database as 
user SYS and then submit the following command: 

CREATE SPFILE = ' spfile.name' FROM MEMORY; 

where spfiic_name is a complete path name, including file name, that points to 
HARD-enabled storage. 

b. Do one of the following: 
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- Create a text initialization parameter file (PFILE) in the default location 
with the following single entry: 

SPFILE = spfile_name 

where spfik_name is the complete path to the SPFILE on HARD-enabled 
storage. 

- On the UNIX and Linux platforms, in the default SPFILE location, create a 
symbolic link to the SPFILE on HARD-enabled storage. 

See Table 2—3 for default name and location information for PFILEs and 
SPFILEs. 

c. Shut down the database instance. 

d. Delete the SPFILE in the default location, 

e. Start up the database instance. 



The SPFILE Initialization Parameter 



The SPFILE initialization parameter contains the name of the current server 
parameter file. When the default ser\'er parameter file is used by the database — that is, 
you issue a STARTUP command and do not specify a PFILE parameter — the value of 
SPFILE is internally set by the server. The SQLTlus command SHOW PARAMETERS 
SPFILE (or any other method of querving the value of a parameter) displays the name 
of the server parameter file that is currently in use. 



Changing Initialization Parameter Values 



The ALTER SYSTEM statement enables vou to set, change, or restore to default the 
values of initialization parameters. If vou are using a text initialization parameter file, 
the ALTER SYSTEM statement changes the value of a parameter only for the current 
instance, because there is no mechanism for automatically updating text initialization 
parameters on disk. You must update them manually to be passed to a future instance. 
Using a server parameter file overcomes this limitation. 

There are two kinds of initialization parameters; 

■ Dynamic initialization parameters can be changed for the current Oracle 
Database instance. The changes take effect immediately, 

■ Static initialization parameters cannot be changed for the current instance. You 
must change these parameters in the text initialization file or server parameter file 
and then restart the database before changes take effect. 

Setting or Changing Initialization Parameter Values 

Use the SET clause of the ALTER SYSTEM statement to set or change initialization 
parameter values. The optional SCOPE clause specifies the scope of a change as 
described in the foUowing table: 
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SCOPE Clause 



Description 



SCOPE = SPFILE The change is applied in the server parameter file only; The effect is 

as follows: 

■ No change is made to the current instance. 

■ For both dynamic and static parameters, the change is effective 
at the next startup and is persistent 

This is the only SCOPE specification allowed for static parameters. 
SCOPE = MEMORY The change is applied in memory only The effect is as follows: 

■ The change is made to the current instance and is effective 
immediately 

■ For dynamic parameters, the effect is immediate, but it is not 
persistent because the server parameter file is not updated. 

For static parameters, this specification is not allowed. 

SCOPE = BOTH The change is applied in both the server parameter file and 

memory The effect is as follows: 

■ The change is made to the current instance and is effective 
imm.ed lately 

■ For dynamic parameters, the effect is persistent because the 
server parameter file is updated. 

For static parameters, this specification is not allowed. 

It is an error to specify SCOPE=SPFILE or SCOPE=BOTH if the instance did not start up 
with a server parameter file. The default is SCOPE=BOTH if a server parameter file was 
used to start up the instance, and MEMORY if a text initialization parameter file was 
used to start up the instance. 

For dynamic parameters, you can also specify the DEFERRED keyword. When 
specified, the change is effective only for future sessions. 

When you specify SCOPE as SPFILE or BOTH, an optional COMMENT clause lets you 
associate a text string with the parameter update. The comment is written to the server 
parameter file. 

The following statement changes the maximum number of failed login attempts before 
the connection is dropped. It includes a comment, and explicitly states that the change 
is to be made only in the server parameter file, 

ALTER SYSTEM SET SEC_MSX_FAILED_L0GIH_ATTEMPTS=3 

COMMENT= 'Reduce from 10 for tighter security.' 
SCOPE=SPFIIE; 

The next example sets a complex initialization parameter that takes a list of attributes. 
Specifically, the parameter value being set is the LOG_ARCHIVE_DEST_n initialization 
parameter. This statement could change an existing setting for this parameter or create 
a new archive destination, 

ALTER SYSTEM 

SEf LOG_ARCHIVE_DEST_4='LOCATIOH=/u02/oracle/rbdbl/' , MANDATORY, 'RE0PEH=2' 
COHMENT='Add new destimation on Nov 29' 
SCOPE=SPFILE; 

When a value consists of a list of parameters, you cannot edit individual attributes by 
the position or ordinal number. You must specifv the complete list of values each time 
the parameter is updated, and the new list completely replaces the old list. 
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Clearing Initialization Parameter Values 



YoLL can use the ALTER SYSTEM RESET command to clear (remove) the setting of any 
initialization parameter in the SPFILE that was used to start the instance. Neither 
SCOPE=MEMORY nor SCOPE=BOTH are allowed. The SCOPE = SPFILE clause is not 
required, but can be included. 

You may want to clear a parameter in the SPFILE so that upon the next database 
startup a default value is used. 

See Also: Oracle Database SQL Language Refcrciia: for information 
about the ALTER SYSTEM command 



Exporting the Server Parameter File 



You can use the CREATE PFILE statement to export a server parameter file (SPFILE) 
to a text initialization parameter file. Doing so might be necessary for several reasons: 

■ For diagnostic purposes, hsting all of the parameter values currently used bv an 
instance. This is analogous to the SQL*Plus SHOW PARAMETERS command or 
selecting from the V$ PARAMETER or V$PARAMETER2 views. 

■ To modify the server parameter file by first exporting it, editing the resulting text 
file, and then re-creating it using the CREATE SPFILE statement 

The exported file can also be used to start up an instance using the PFILE clause. 

You must have the SYSDBA or the SYSOPER system privilege to execute the CREATE 
PFILE statement The exported file is created on the database server machine. It 
contains anv comments associated with the parameter in the same line as the 
parameter setting. 

The following example creates a text initialization parameter file from the SPFILE: 

CREATE PFILE FROM SPFILE; 

Because no names were specified for the files, the database creates an initialization 
parameter file with a platform- specific name, and it is created from the 
platform- specific default server parameter file. 

The following example creates a text initialization parameter file from a server 
parameter file, but in this example the names of the files are specified: 

CREATE PFILE=Vu01/oracle/dl)s/test_init.ora' 

FROM SPFILE=7u01/aracle/dbs/test_spfile.ora',- 



Note: An alternative is to create a PFILE from the current values of 
the initialization parameters in memory. The following is an example 
of the required command: 

CREATE PFILE='/u01/oracle/dl)s/test_iriit.ora' FROM MEMORY; 



Backing Up the Server Parameter File 



You can create a backup of vour server parameter file (SPFILE) by exporting it, as 
described in "Exporting the Server Parameter File", If the backup and recoverv strategv 
for your database is implemented using Recoverv Manager (RMAN), then you can use 
RMAN to create a backup of the SPFILE, The SPFILE is backed up automatically by 
RMAN when vou back up vour database, but RMAN also enables you to specificallv 
create a backup of the currently active SPFILE. 
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See Also: Oracle Database Backup and Recovery User's Guide 

Recovering a Lost or Damaged Server Parameter File 

If your server parameter file (SPFILE) becomes lost or corrupted, the current instance 
mav fail, or the next attempt at starting the database instance mav fail. There are a 
number of wavs to recover the SPFILE: 

■ If the instance is running, issue the following command to recreate the SPFILE 
from the current values of initiahzation parameters in memory: 

CREATE SPFII£ FROM MEMORY; 

This command creates the SPFILE with the default name and in the default 
location. You can also create the SPFILE with a new name or in a specified 
location. See "Creating a Server Parameter File" on page 2-32 for exiimples. 

■ If vou have a valid text initialization parameter file (PFILE), recreate the SPFILE 
from the PFILE with the following command: 

CREATE SPFII£ FROM PFII£; 

This command assumes that the PFILE is in the default location and has the 
default name. See "Creating a Ser\'er Parameter File" on page 2-32 for the 
command svntax to use when the PFILE is not in the default location or has a 
non-default name, 

■ Restore the SPFILE from backup. 

See "Backing Up the Server Parameter File" on page 2-38 for more information. 

■ If none of the previous methods are possible in your situation, perform these 
steps: 

1. Create a text initialization parameter file (PFILE) from the parameter value 
listings in the alert log. 

When an instance starts up. the initialization parameters used for startup are 
written to the alert log. You can copv and paste this section from the text 
version of the alert log (without XML tags) into a new PFILE. 

See "Viewing the Alert Log" on page S-18 for more information. 

2. Create the SPFILE from the PFILE. 

See "Creating a Server Parameter File" on page 2-32 for instructions. 

Read/Write Errors During a Parameter Update 

If an error occurs while reading or writing the ser\'er parameter file during a 
parameter update, the error is reported in the alert log and all subsequent parameter 
updates to the server parameter file are ignored. At this point, vou can take one of the 
following actions: 

■ Shut down the instance, recover the server parameter file and described earlier in 
this section, and then restart the instance. 

■ Continue to run the database if vou do not care that subsequent parameter 
updates will not be persistent. 

Viewing Parameter Settings 

You can view parameter settings in several wavs, as shown in the following table. 
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Method 


Description 


SHOW PAEftMETERS 


This SQL*Plus command displiivs the values of initiahzation 
parameters in effect for the current session. 


SHOW SPPARAMETERS 


This SQL'Plus command displays the values of initialization 
parameters in the server parameter file (SPFILE). 


CREATE PFILE 


This SQL statement creates a text initialization parameter file 
(PHLE) from the SPHLE or from the current in-memory settings. 
You can then view the PFILE with any te\t editor. 


V$ PiiRfiMETEH 


This view displays the values of initialization parameters in 
effect for the current session. 


V? PaRfiMETER2 


This view displays the values of initialization parameters in 
effect for the current session. It is easier to distinguish list 
parameter values in this view because each list parameter value 
appears in a separate row. 


VS SYS TEM_PARAMETER 


This view displays the values of initialization parameters in 
effect for the instance. A new session inherits parameter values 
from the instance-wide values. 


VS SYS TEH_PARAMETER2 


This view displays the values of initialization parameters in 
effect for the instance. A new session inherits parameter values 
from the instance-wide values. It is easier to distinguish list 
parameter values in this view because each list parameter value 
appears in a separate row. 


VSSPPARAMETER 


This view displays the current contents of the SPHLE The view 
returns FALSE values in the I3SPECIF 1 hll) column if an SPFILE 
is not being used by the instance. 



See Also: Oracle Database Rejerence for a complete description of 
vievifs 

Defining Database Services 

This section describes database ser\'ices and includes the following topics: 

■ Deploying Services 

■ Configuring Seryices 

■ Using Seryices 

Database services (seryices) are logical abstractions for managing ivorkloads in Oracle 
Database. Services divide workloads into mutually disjoint groupings. Each ser\'ice 
represents a workload with common attributes, service-leyel thresholds, and priorities. 
The grouping is based on attributes of work that might include the application 
function to be used, the priorit}" of execution for the application function, the job class 
to be managed, or the data range used in the application function or job class. For 
example, the Oracle E-Business suite defines a service for each responsibility, such as 
general ledger, accounts recei\'able, order entry, and so on. Each database service has a 
unique name. 

Connection requests can include a database service name. If no service name is 
included and the Net Services file listenerora designates a default service, the 
connection uses the default service. 

Services are built into the Oracle Database, providing a single system image for 
workloads, prioritization for workloads, performance measures for real transactions, 
and alerts and actions when performance goals are violated. Services enable you to 
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configure a workload, administer it, enable and disable it, and measure the workload 
as a single entit}'. You can do this using standard tools such as the Database 
Configuration Assistant (DBCA), Net Configuration Assistant (NetCA), and Enterprise 
Manager (EM). Enterprise Manager supports viewing and operating services as a 
whole, with drill down to the instance-level when needed. 

In Real Application Clusters (RAC), a service can span one or more instances and 
facilitate real workload balancing based on real transaction performance. This 
provides end-to-end unattended recovery, rolling changes by workload, and full 
location transparency. RAC also enables you to manage a number of service features 
with Enterprise Manager, the DBCA, and the Server Control utilit}' (SRVCTL), 

Services also offer an extra dimension in performance tuning. Tuning by "service and 
SQL" can replace tuning by "session and SQL" in the majorit}' of systems where all 
sessions are anonymous and shared. With services, workloads are visible and 
measurable. Resource consumption and waits are attributable bv application. 
Additionallv, resources assigned to services can be augmented when loads increase or 
decrease. This dynamic resource allocation enables a cost-effective solution for 
meeting demands as they occur. For example, services are measured automatically 
and the performance is compared to service-level thresholds. Performance violations 
are reported to Enterprise Manager, enabling the execution of automatic or scheduled 
solutions. 

See Also: Oracle Real AppUcation Clusters Administration and 
Deplo^me/it Guide 



Deploying Services 



When you configure database services, you give each service a unique global name, 
associated performance goals, and associated importance. The services are tightly 
integrated with Oracle Database and are maintained in the data dictionary. You can 
find service information in the following service- specific views: 

DBA_SERVICES 

ALL_SERVICES orV$SERVICES 
V$ACTIVE_SERVICES 

VSSERVICE_STATS 

VSSERVICE_EVENTS 

VSSERVICE_WAIT_CLASSES 

VSSERV_MOD_ACT_STATS 

VSSERVICE_METRICS 

V$ SERVICE_METRICS_HI STORY 

The following additional views also contain some information about services: 

VSSESSION 

V$ACTIVE_SES SI ON_HI STORY 

DBA_RSRC_GROUP_MAPPINGS 

DBA_SCHEDULER_JOB_CLASSES 

DBA THRESHOLDS 
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See Also: Oracle Database Reference for detailed information about 
these views 

Several Oracle Database features support services. The Automatic Workload 
Repository (AWR) manages the performance of services. AWR records service 
performance, including execution times, wait classes, and resources consumed by 
service. AWR alerts warn when service response time thresholds are exceeded. The 
dynamic views report current service performance metrics with one hour of history. 
Each service has quality-of-service thresholds for response time and CPU 
consumption. 

In addition, the Database Resource Manager maps services to consumer groups. This 
enables you to automatically manage the prioritv of one service relative to others. You 
can use consumer groups to define relative prioritv in terms of either ratios or resource 
consumption. This is described in more detail, for example, in Orach Real Application 
Clusters Deployment and Performance Guide. 



Configuring Services 



Services describe applications, application functions, and data ranges as either 
functional services or data -dependent services. Functional services are the most 
common mapping of workloads. Sessions using a particular function are grouped 
together For Oracle 'Applications, ERF, CRM, and (Support functions create a 
functional division of the work. For SAP, dialog and update functions create a 
functional division of the work. 

In contrast, data- dependent routing routes sessions to services based on data kevs. The 
mapping of work requests to services occurs in the object relational mapping layer for 
application servers and TP monitors. For example, in RAC, these ranges can be 
completely dynamic and based on demand because the database is shared. 

You can also define preconnect application services in RAC databases, Preconnect 
services span instances to support a ser\'ice in the event of a failure. The preconnect 
service supports TAF preconnect mode and is managed transparently when using 
RAC, 

In addition to application services, Oracle Database also supports two internal 
services: SYSSBACKGROUND is used by the background processes only and 
SYSSUSERS is the default service for user sessions that are not associated with 
services. 

Use the DBMS_SERVICE package or set the SERVICE_NAMES parameter to create 
application services on a single- instance Oracle Database, You can later define the 
response time goal or importance of each service through EM, either individuallv or 
bv using the Enterprise Manager feature "Copy Thresholds From a Baseline" on the 
Manage Metrics/Edit Threshold pages. You can also do this using PL /SQL, 



Using Services 



Using services requires no changes to your application code. Client-side work 
connects to a service. Server-side work specifies the service when creating the job class 
for the Job Scheduler and the database links for distributed databases. Work requests 
executing under a service inherit the performance thresholds for the service and are 
measured as part of the service. 
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Client-Side Use 

Middle-tier applications and client-server applications use a sen'ice by specifying the 
service as part of the connection in TNS connect data. This connect data may be in the 
TNSnames file for thick Net drivers, in the URL specification for thin drivers, or mav 
be maintained in the Oracle Internet Directory, For example, data sources for the 
Oracle Application Server are set to route to a service. Using easy connect naming, this 
connection needs only the host name and service name (for example, 
iurSmyDBhoat/myaervice). For Oracle E-Business Suite, the service is also 
maintained in the application database identifier and in the cookie for the ICX 
parameters. 

Server-Side Use 

Server-side work, such as Oracle Scheduler, parallel execution, and Oracle Stream.s 
Advanced Queuing, set the service name as part of the workload definition. 

For Oracle Scheduler, the service that the job class uses is optionally defined when the 
job class is created. During execution, jobs are assigned to job classes, and job classes 
can run within services. Using services with job classes ensures that the work executed 
by the job scheduler is identified for workload management and performance tuning. 

For parallel query and parallel DML, the query coordinator connects to a service just 
like any other client. The parallel querv processes inherit the service for the duration of 
the execution. At the end of querv execution, the parallel execution processes revert to 
the default service. 

See Also: Chapter 27, "Scheduling Jobs with Oracle Scheduler" for 
more information about the Oracle Scheduler. 



Considerations After Creating a Database 



After vou create a database as described in "Creating a Database with DBCA" on 
page 2A or "Creating a Database with the CREATE DATABASE Statement" on 
page 2A, the instance is left running, and the database is open and available for 
normal database use. You may want to perform other actions, some of which are 
discussed in this section. 

Some Security Considerations 

In this release of Oracle Database, several enhancements were made to ensure the 
security your database. You can find securit\' guidelines for this release in Oracle 
Dalalwse Seairify Guide. Oracle recommends that vou read these guidelines and 
configure your database accordingly. 

After the database is created, you can configure it to take advantage of Oracle Identity 
Management. For information on how to do this, please refer to Oracle Database 
Enterprise User Security Administrator's Guide. 

A newly created database has at least three user accounts that are important for 
administering your database: SYS, SYSTEM, and SYSMAN. Additional administrative 
accounts are provided that should be used onlv bv authorized users. To protect these 
accounts from being used bv unauthorized users familiar with their Oracle- sup plied 
passwords, these accounts are initially locked with their passwords expired. As the 
database administrator, vou are responsible for the unlocking and resetting of these 
accounts. 

See Oracle Database 2 Day + Security Guide for a complete list of predefined user 
accounts created with each new Oracle Database installation. 
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Caution: To prevent unauthorized access and protect the integrity 
of your database, it is important that new passwords for user 
accounts SYS and SYSTEM be specified when the database is 
created. This is accomplished by specifying the following CREATE 
DATABASE clauses when manually creating you database, or by 
using DBCA to create the database: 

■ USER SYS IDENTIFIED BY 

■ USER SYSTEM IDENTIFIED BY 



See Also: 



"Administrative User Accounts" on page 1-13 for more 
information about the users SYS and SYSTEM 

Orack' Database Security Guide to learn how to add new users 
and change passwords 

Oracle Database SQL Language Reference for the svntax of the 
ALTER USER statement used for unlocking user accounts 



Enabling Transparent Data Encryption 

Transparent data encrvption is a feature that enables encrvption of individual 
database columns before storing them in the datafile. or enables encn'ption of entire 
tablespaces. If users attempt to circumvent the database access control mechanisms by 
looking inside datafiles directiv with operating system tools, transparent data 
encryption prevents such users from viewing sensitive information. 

Users who have the CREATE TABLE privilege can choose one or more columns in a 
table to be encry'pted. The data is encrypted in the data files and in the audit logs (if 
audit is turned on). Database users with appropriate privileges can view the data in 
unencrypted format. For information on enabling and disabling transparent data 
encryption, see Oracle Database Advanced Security Administrator's Guide. 

See Also: 

■ "Consider Encr\'pting Columns That Contain Sensitive Data" on 
page 18-6 

■ "Encrypted Tablespaces" on page 12-8 

Creating a Secure External Password Store 

For large-scale deployments where applications use password credentials to connect 
to databases, it is possible to store such credentials in a client-side Oracle wallet. An 
Oracle wallet is a secure software container that is used to store authentication and 
signing credentials. 

Storing database password credentials in a client-side Oracle wallet eliminates the 
need to embed usernames and passwords in application code, batch jobs, or scripts. 
This reduces the risk of exposing passwords in the clear in scripts and application 
code, and simplifies maintenance because you need not change your code each time 
usernames and passwords change. In addition, not having to change application code 
also makes it easier to enforce password management policies for these user accounts. 

When you configure a client to use the external password store, applications can use 
the following syntax to connect to databases that use password authentication: 
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COHHECT /@datah6ise_alias 

Note that voli need not specify dat.ibiise login credentials in this CONNECT statement. 
Instead vour svsteni looks for database login credentials in the client wallet. 

See Also: Oracle Database Advanced Seciiritij AihnhiisSrator's Guide for 
information about configuring yotir client to use a secure external 
password store and for information about managing credentials in it. 

Installing the Oracle Database Sample Schemas 

The Oracle Database distribution media includes various SQL files that let vou 
experiment with the system, learn SQL, or create additional tables, views, or 
synonyms, 

Oracle Database includes sample schemas that help vou to become familiar with 
Oracle Database functionalit\". All Oracle Database documentation and training 
materials are being converted to the Sample Schemas en\'ironment as those materials 
are updated. 

The Sample Schemas can be installed automatically bv the Datiibase Configuration 
Assistant, or you can install them manually. The schemas and installation instructions 
are described in detail in Oracle Database Sample Schemas. 



Database Data Dictionary Views 



In addition to the views listed previously in "Viewing Parameter Settings", you can 
view information about your database content and structure using the following 
views: 

View Description 

DATABASE_PROPERTIES Displays permanent database properties 



GLOBAL_HflME Displays the global database name 



VSDATABASE Contains database information from the control file 
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Starting Up and Shutting Down 



In this chapter: 

Starting Up a Datah.ise 

Altering Database Availability 

Shutting Down a Database 

Quiescing a Database 

Suspending and Resuoking a Database 

See Also: Oracle Real Application Clusters Administraiion and 
Dcphijmcnt Guide for additional information specific to an Oracle 
Real Application Clusters environment 



Starting Up a Database 



When you start up a database, vou create an instance of that database and vou 
determine the state of the database. Normally, you start up an instance bv mounting 
and opening the database. Doing so makes the database available for anv valid user to 
connect to and perform t}'pical data access operations. Other options exist, and these 
are also discussed in this section. 

This section contains the following topics relating to starting up an instance of a 
database: 

■ Options for Starting Up a Database 

■ Understanding Initialization Parameter Files 

■ Preparing to Start Up an Instance 

■ Starting Up an Instance 



Options for Starting Up a Database 



YoLi can start up a database instance with SQL*Pius, Recovery Manager, or Enterprise 
Manager. 

Starting Up a Database Using SQL^PIus 

YoLL can start a SQL'*Pkis session, connect to Oracle Database with administrator 
privileges, and then issue the STARTUP command. Using SQL*Plus in this w^av is the 
onlv method described in detail in this book. 
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Starting Up a Database Using Recovery Manager 

You can also use Recovery Manager (RMAN) to execute STARTUP and SHUTDOWH 
commands. You may prefer to do this if your are within the RMAN environment and 
do not want to invoke SQL'Plus, 

See Also: Oracle Database Backup and Recovery User's Guide for 
information on starting up the database using RMAN 

Starting Up a Database Using Oracie Enterprise Manager 

You can use Oracle Enterprise Manager (EM) to administer vour database, including 
starting it up and shutting it down. EM combines a GUI console, agents, common 
services, and tools to provide an integrated and comprehensive systems management 
platform for managing Oracle products, EM Database Control, which is the portion of 
EM that is dedicated to administering an Oracle database, enables you to perform the 
functions discussed in this book using a GUI interface, rather than command line 
operations. 

See Also: 

■ Oracle Enterprise Manager Concepts 

■ Oracle Enterprise Manager Grid Control Installation and Basic 
Configuration 

Oracle Database 2 Day DBA 
The remainder of this section describes using SQL*Plus to start up a database instance. 

Understanding Initialization Parameter Files 

To start an instance, the database must read instance configuration parameters (the 
initialization parameters) from either a sen'er parameter file (SPFILE) or a text 
initialization parameter file. 

When you issue the SQL'Plus STARTUP command, the database attempts to read the 
initialization parameters from an SPFILE in a platform -specific default location. If it 
finds no SPFILE, it searches for a text initialization parameter file. 



Note: For UNIX or Linux, the platform-specific default location 
(directory) for the SPFILE and text initialization parameter file is: 

50RACLE_H0ME/dbs 

For Windows NT and Windows 2000 the location is: 

%ORACLE_HOME% \database 

In the platform-specific default location, Oracle Database locates your initialization 
parameter file by examining filenames in the following order: 

1. s-pf lie $ORACLE_SID.o:r: a 

2. spf lie . ora 

3. lnlt$0RACLE_SID.OTa 

The first tivo filenames represent SPFILEs and the third represents a text initialization 
parameter file. 
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Note: The spf ile . ora file is included in this search path 
because in an Oracle Real Application Clusters environment one 
server parameter file is used to store the initialization parameter 
settings for all instances. There is no instance- specific location for 
storing a ser\'er parameter file. 

For more information about the server parameter file for an Oracle 
Real Application Clusters environment, see Oracle Real Application 
Cliiiten Administration and Deployment Guide. 



If vou (or the Database Configuration Assistant) created a server parameter file, but 
you want to override it with a text initialization parameter file, vou can specifv the 
PFILE clause of the STARTUP command to identify the initialization parameter file. 

STARTUP PFILE = /"uOl/oracle/dbs/init.ora 

Starting Up with a Non-Detault Server Parameter File 

A non-default server parameter file (SPFILE) is an SPFILE that is in a location other 
than the default location. It is not usuaUy necessarv to start an instance with a 
non-default SPFILE. However, should such a need arise, vou can use the PFILE 
clause to start an instance with a non-default server parameter file as follows: 

1. Create a one-line text initialization parameter file that contains onlv the SPFILE 
parameter The value of the parameter is the non-default ser\er parameter file 
location. 

For example, create a text initialization parameter file 

/uOl/oracle/dbs/ spf_init . ora that contains only the following parameter; 

SPFILE = /u01/aracle/dbs/test_spfile.ora 

Note: You cannot use the IFILB initialization parameter within a 
text initialization parameter file to point to a ser\'er parameter file. 
In this context, you must use the SPFILE initialization parameter. 



2. Start up the instance pointing to this initialization parameter file. 

STARTUP PFILE = /"uOl/oracle/dbs/spfjnit.ora 

The SPFILE must reside on the machine running the database server. Therefore, the 
preceding method also provides a means for a client machine to start a database that 
uses an SPFILE. It also eliminates the need for a client machine to maintain a 
chent-side initialization parameter file. When the client machine reads the 
initialization parameter file containing the SPFILE parameter, it passes the value to 
the server w^here the specified SPFILE is read. 

Note that on the UNIX and Linux platforms, if vour SPFILE is not in the default 
location, you can also create a symbolic hnk to the SPFILE and place the symbolic hnk 
in the default location. 

See Table 2-3 on page 2-33 for information on PFILE and SPFILE default names and 
locations. 

Initialization Files and Automatic Storage Management 

A database that uses Automatic Storage Management (ASM) usually has a non-default 
SPFILE. If vou use the Database Configuration Assistant (DBCA) to configure a 
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database to use ASM, DBCA creates an SPFILE for the database instance in an ASM 
disk group, and then creates a text initialization parameter file in the default location 
in the local file system to point to the SPFILE. 

See Also: Chapter 2, "Creating and Configuring an Oracle 
Database", for more information about initialization parameters, 
initialization parameter files, and server parameter files 



Preparing to Start Up an Instance 



You must perform some preliminary steps before attempting to start an instance of 
your database using SQL*Plus. 

1. Ensure that environment variables are set so that vou connect to the desired 
Oracle instance. For details, see "Submitting Commands and SQL to tlie Database" 
on page 1-6. 

2. Start SQL'Plus without connecting to the database: 

SQLPLUS /MOLOG 

3. Connect to Oracle Database as SYSDBA: 
COMMECT usernarae AS SYSDBA 

Now you are connected to the database and readv to start up an instance of vour 
database. 

See Also: SQL* Plus User's Guide and Reference ior descriptions and 
svntax for the COWWECT, STARTUP, and SHUTDOWN commands. 



Starting Up an Instance 



You use the SQL*Plus STARTUP command to start up an Oracle Database instance. 
You can start an instance in various modes: 

■ Start the instance without mounting a database. This does not allow access to the 
database and usually would be done onJv for database creation or the re-creation 
of control files. 

■ Start the instance and mount the database, but leave it closed. This state allows for 
certain DBA activities, but does not allow general access to the database. 

■ Start the instance, and mount and open the database. This can be done in 
unrestricted mode, allowing access to all users, or in restricted mode, allowing 
access for database administrators only. 

■ Force the instance to start after a startup or shutdown problem, or start the 
instance and have complete media recovery begin immediately. 

Note: You cannot start a database instance if vou are connected to 
the database through a shared server process. 



The following scenarios describe and illustrate the various states in which you can 
start up an instance. Some restrictions apply when combining clauses of the STARTUP 
command. 
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Note: It is possible to encounter problems starting up an instance 
if control files, database files, or redo log files are not available. If 
one or more of the files specified by the CONTROL_FILES 
initialization parameter does not exist or cannot be opened when 
you attempt to mount a database, Oracle Database returns a 
warning message and does not mount the database. If one or more 
of the datafiles or redo log files is not available or cannot be opened 
when attempting to open a database, the database returns a 
warning message and does not open the database. 



See Also: SQfPliis Usit's Guide mid Reference for information 
about the restrictions that apply when combining clauses of the 
STARTUP command 

Starting an Instance, and Mounting and Opening a Database 

Normal database operation means that an instance is started and the database is 
mounted and open. This mode allows anv valid user to connect to the database and 
perform, data access operations. 

The following command starts an instance, reads the initialization parameters from 
the default location, and then mounts and opens the database. (You can optionally 
specify a PFILE clause.) 

STARTUP 

Starting an Instance Witliout Mounting a Database 

You can start an instance without mounting a database. Tvpically, you do so only 
during database creation. Use the STARTUP command with the NOMOUWT clause; 

STARTUP KOMOUHT 

Starting an Instance and Mounting a Database 

You can start an instance and mount a database without opening it, allow^ing vou to 
perform specific maintenance operations. For example, the database must be mounted 
but not open during the following tasks: 

■ Enabling and disabling redo log archiving options. For more information, please 
refer to Chapter 11, "Managing Archived Redo Logs", 

■ Performing full database recovery. For more information, please refer to Oracle 
Database Backu].' and Recovery User's Guide 

The following command starts an instance and mounts the database, but leaves the 
database closed: 

STARTUP MOUNT 

Restricting Access to an Instance at Startup 

You can start an instance, and optionallv mount and open a database, in restricted 
mode so that the instance is available only to administrative personnel (not general 
database users). Use this mode of instance starlTip when you need to accomplish one 
of the following tasks: 

■ Perform an export or import of data 

■ Perform a data load (withSQL'Loader) 
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■ Temporarily prevent typical users from using data 

■ Perform certain migration or upgrade operations 

Tvpicallv, all users with tlie CREATE SESSION system privilege can connect to an 
open database. Opening a database in restricted mode allows database access onlv to 
users with both the CREATE SESSION and RESTRICTED SESSION system privilege. 
Only database administrators should liave tlie RESTRICTED SESSION system 
privilege. Further, when tlie instance is in restricted mode, a database administrator 
cannot access the instance remotely througli an Oracle Net listener, but can only access 
the instance locally from the machine that the instance is running on. 

The following command starts an instance (and mounts and opens the database) in 
restricted mode: 

STARTUP RESTRICT 

You can use the RESTRICT clause in combination with the MOUNT, NOMOUWT, and 

OPEN clauses. 

Later, use the ALTER SYSTEM statement to disable the RESTRICTED SESSION 
feature: 

ALTER SYSTEM DISABLE RESTRICTED SESSIOH; 

If vou open the database in nonrestricted mode and later find that you need to restrict 
access, you can use the ALTER SYSTEM statement to do so, as described in "Restricting 
Access to an Open Database" on page 3-8, 

See Also: Oracle Database SQL Language Reference for more 
information on the ALTER SYSTEM statement 

Forcing an Instance to Start 

In unusual circumstances, you might experience problems when attempting to start a 
database instance. You should not force a database to start unless you are faced with 
the following: 

■ You cannot shut down the current instance with the SHUTDOWN NORMAL, 

SHUTDOWN IMMEDIATE, or SHUTDOWN TRANSACTIONAL commands. 

■ You experience problems when starting an instance. 

If one of these situations arises, vou can usually solve the problem by starting a new 
instance (and optionallv mounting and opening the database) using the STARTUP 
command with the FORCE clause: 

STARTUP FORCE 

If an instance is running, STARTUP FORCE shuts it down with mode ABORT before 
restarting it. In this case, beginning with Oracle Database lOg Release 2, the alert log 
shows the message "Shutting down instance (abort ) " followed by "Star ting 
ORACLE instance (normal ) ." (Earlier versions of the database showed only 
"starting ORACLE instance (force) " in the alert log.) 

See Also: "Shutting Down with the ABORT Clause" on page 3-10 
to understand the side effects of aborting the current instance 
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Starting an Instance, Mounting a Database, and Starting Complete Media Recovery 

If voLL know that media recoven' is required, vou can start an instance, mount a 
database to the instance, and have the recoverv process automatically start by using 
the STARTUP command with the RECOVER clause: 

STARTUP OPEH RECOVER 

If VOU attempt to perform recoverv when no recovery is required, Oracle Database 
issues an error message. 

Automatic Database Startup at Operating System Start 

Many sites use procedures to enable automatic startup of one or more Oracle Database 
instances and databases immediately following a system start. The procedures for 
performing this task are specific to each operating system. For information about 
automatic startup, see your operating system specific Oracle documentation. 

Starting Remote Instances 

If your local Oracle Database server is part of a distributed database, you might want 
to start a remote instance and database. Procedures for starting and stopping remote 
instances vary widely depending on communication protocol and operating system. 



Altering Database Availability 



You can alter the availability of a database. You may want to do this in order to restrict 
access for maintenance reasons or to make the database read only. The following 
sections explain how to alter the availabiiit)' of a database: 

■ Mounting a Database to an Instance 

■ Opening a Closed Database 

■ Opening a Database in Read-Only Mode 

■ Restricting Access to an Open Database 



Mounting a Database to an Instance 



When you need to perform specific administrative operations, the database must be 
started and mounted to an instance, but closed. You can achieve this scenario by 
starting the instance and mounting the database. 

To mount a database to a previously started, but not opened instance, use the SQL 
statement ALTER DATABASE with the MOUNT clause as follows: 

ALTER DATABASE HOUMT,- 

See Also: "Starting an Instance and Mounting a Database" on 
page 3-5 for a hst of operations that require the database to be 
mounted and closed (and procedures to start an Instance and 
mount a database in one step) 



Opening a Closed Database 



You can make a mounted but closed database available for general use by opening the 
database. To open a mounted database, use tlie ALTER DATABASE statement with the 
OPEN clause: 

ALTER DATABASE OPEN; 
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After executing this statement, .inv viilid Oracle Database user with the CREATE 
SESSION system privilege Ctin connect to the database. 



Opening a Database in Read-Only Mode 



Opening a database in read-onlv mode enables ;'ou to query an open database while 
eliminating any potential for online data content changes. While opening a database in 
read-onlv mode guarantees that datafile and redo log files are not written to, it does 
not restrict database recovery or operations that change the state of the database 
without generating redo. For example, vou can take datafiles offline or bring them 
online since these operations do not affect data content. 

If a quen' against a database in read-onlv mode uses temporary tablespace, for 
example to do disk sorts, then the issuer of the query must have a locallv managed 
tablespace assigned as the default temporary tablespace. Otherwise, the quer;' will fail. 
This is explained in "Creating a Locallv Managed Temporarv Tablespace" on 
page 12-11. 

The following statement opens a database in read-only mode: 

ALTER DATABASE OPEH READ ONLY; 

You can also open a database in read/write mode as follows: 

ALTER DATABASE OPEH READ WRITE; 

However, read/write is the default mode. 

Note: Youcannot use the RESETLOGS clause with a READ ONLY 
clause. 



See Also: Orach Database SQL Language Reference for more 
information about the ALTER DATABASE statement 



Restricting Access to an Open Database 



To place an instance in restricted mode, where onlv users with administrative 
privileges can access it, use the SQL statement ALTER SYSTEM with the EHABLE 
RESTRICTED SESSION clause. After placing an instance in restricted mode, you 
should consider kiUing all current user sessions before performing any administrative 
tasks. 

To lift an instance from restricted mode, use ALTER SYSTEM with the DISABLE 

RESTRICTED SESSION clause. 

See Also: 

■ "Terminating Sessions" on page 4-22 for directions for killing 
user sessions 

■ "Restricting Access to an Instance at Startup" on page 3-E> to 
learn some reasons for placing an instance in restricted mode 



Shutting Down a Database 



To initiate database shutdow^n, use the SQL*Plus SHUTDOWN command. Control is not 
returned to the session that initiates a database shutdown until shutdown is complete. 
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Users who attempt connections while a shutdown is in progress receive a message like 
the following: 

ORA-D1090: shutdown in progress - connection is not permitted 



Note: You cannot shut down a database if you are connected to 
the database through a shared server process. 

To shut down a database and instance, you must first connect as SYSOPER or SYSDBA. 
There are several modes for shutting down a database. These are discussed in the 
following sections: 

. Shutting Down with the NORMAL Clause 

. Shutting Down with the IMMEDIATE Clause 

. Shutting Down with the TRANSACTIONAL Clause 

. Shutting Down with the ABORT Clause 

Some shutdow^n modes wait for certain events to occur (such as transactions 
completing or users disconnecting) before actuallv bringing down the database. There 
is a one-hour timeout period for these events. This timeout behavior is discussed in 
this additional section: 

■ Shutdown Timeout and Abort 



Shutting Down with the NORMAL Clause 



To shut down a database in normal situations, use the SHUTDOWN command with the 
NORMAL clause: 

SHUTDOWN NORMAL 

The NORMAL clause is optional, because this is the default shutdown method if no 
clause is provided. 

Normal database shutdown proceeds with the following conditions: 

■ No new connections are allowed after the statement is issued. 

■ Before the database is shut down, the database waits for all currentlv connected 
users to disconnect from the database. 

The next startup of the database will not require any instance recovery procedures. 

Shutting Down with the IMI\/IEDIATE Clause 

Use immediate database shutdown only in the following situations: 

■ To initiate an automated and unattended backup 

■ When a power shutdown is going to occur soon 

■ When the database or one of its apphcations is functioning irregularlv and vou 
cannot contact users to ask them to log off or they are unable to log off 

To shut down a database Lmmediately, use the SHUTDOWN command with the 
IMMEDIATE clause: 

SHUTDOWN MHEDIATE 

Immediate database shutdown proceeds with the follow^ing conditions: 
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■ No new connections are allowed, nor are new transactions allowed to be started, 
after the statement is issued. 

■ Any uncommitted transactions are rolled back, (If long uncommitted transactions 
exist, this method of shutdown might not complete quickly, despite its name.) 

■ Oracle Database does not wait for users currently connected to the database to 
disconnect. The database implicitly rolls back active transactions and disconnects 
all connected users. 

The next startup of the database will not require any instance recovery procedures. 

Shutting Down with the TRANSACTIONAL Clause 

When you want to perform a planned shutdown of an instance while allowing active 
transactions to complete first, use the SHUTDOWN command with the TRAHSACTIOHAL 
clause: 

SHUTDOWN TRANSACTIONAL 

Transactional database shutdown proceeds with the following conditions: 

■ No new connections are allowed, nor are new transactions allowed to be started, 
after the statement is issued, 

■ After all transactions have completed, any client still connected to the instance is 
disconnected. 

■ At this point, the instance shuts down just as it would when a SHUTDOWN 
IMMEDIATE statement is submitted. 

The next startup of the database will not require any instance recovery procedures. 

A transactional shutdown prevents clients from losing work, and at the same time, 
does not require all users to log off. 



Shutting Down with the ABORT Clause 



You can shut down a database instantaneously by aborting the database instance. If 
possible, perform this type of shutdown only in the following situations: 

The database or one of its applications is functioning irregularly and none of the other 
types of shutdown works, 

■ You need to shut down the database instantaneously (for example, if you know a 
power shutdown is going to occur in one minute), 

■ You experience problems when starting a database instance. 

When you must do a database shutdown by aborting transactions and user 
connections, issue the SHUTDOWN command with the ABORT clause: 

SHUTDOWN ABORT 

An aborted database shutdown proceeds with the following conditions: 

■ No new connections are aUowed, nor are new transactions allowed to be started, 
after the statement is issued. 

■ Current client SQL statements being processed by Oracle Database are 
immediately terminated. 

■ Uncommitted transactions are not rolled back. 
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■ Oracle Database does not wait for users currently connected to the database to 
disconnect The database implicitly disconnects all connected users. 

The next startup of the database luill require instance recoyery procedures. 



Shutdown Timeout and Abort 



Shutdown modes that wait for users to disconnect or for transactions to complete have 
a limit on the amount of time that thev wait If all events blocking the shutdown do 
not occur within one hour, the shutdown command aborts with the following 
message: ORA- 01 013 : user requested cancel of current operation, 
This message is also displayed if vou interrupt the shutdown process, for example bv 
pressing CTRL-C, Oracle recommends that you do not attempt to interrupt an instance 
shutdown. Instead, allow the shutdown process to complete, and then restart the 
instance. 

After ORA- 01013 occurs, vou must consider the instance to be in an unpredictable 
state. You must therefore continue the shutdown process bv resubmitting a SHUTDOWN 
command. If subsequent SHUTDOWN commands continue to fail, vou must submit a 
SHUTDOWN ABORT command to bring down the instance. You can then restart the 
instance. 



Quiescing a Database 



Occasionally you might want to put a database in a state that allow^s only DBA 
transactions, queries, fetches, or PL/SQL statements. Such a state is referred to as a 
quiesced state, in the sense that no ongoing non-DBA transactions, queries, fetches, or 
PL/SQL statements are running in the system. 

Note: In this discussion of quiesce database, a DBA is defined as 
user SYS or SYSTEM, Other users, including those with the DBA 
role, are not allowed to issue the ALTER SYSTEM QUIESCE 
DATABASE statement or proceed after the diitabase is quiesced. 



The quiesced state lets administrators perform actions that cannot safely be done 
otherwise. These actions include: 

■ Actions that fail if concurrent user transactions access the same object— for 
example, changing the schema of a database table or adding a column to an 
existing table where a no-wait lock is required, 

■ Actions whose undesirable intermediate effect can be seen by concurrent user 
transactions—for example, a multistep procedure for reorganizing a table when the 
table is first exported, then dropped, and finally imported, A concurrent user who 
attempts to access the table after it was dropped, but before import, would not 
have an accurate view of the situation. 

Without the ability to quiesce the database, you would need to shut down the 
database and reopen it in restricted mode. This is a serious restriction, especially for 
systems requiring 24 x 7 availability', Quiescing a database is much a smaller 
restriction, because it eliminates the disruption to users and the downtime associated 
with shutting down and restarting the database. 

When the database is in the quiesced state, it is through the facilities of the Database 
Resource Manager that non-DBA sessions are prevented from becoming active. 
Therefore, while this statement is in effect, any attempt to change the current resource 
plan will be queued until after the system is unquiesced. See Chapter 25, "Managing 
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Resource Allocation with Oracle Dat.ihiise Resource Manager" for more information 
about the Database Resource Manager. 

Placing a Database into a Quiesced State 

To place a database into a quiesced state, issue the following statement: 

ALTER SYSTEM QUIESCE RESTRICTED; 

Non-DBA active sessions will continue until thev become inactive. An active session is 
one that is currently inside of a transaction, a quen', a fetch, or a PL/SQL statement; or 
a session that is currentlv holding anv shared resources (for example, enqueues). No 
inactive sessions are allowed to become active. For example. If a user issues a SQL 
query in an attempt to force an inactive session to become active, the querv will appear 
to be hung. When the database is later unquiesced, the session is resumed, and the 
blocked action is processed. 

Once all non-DBA sessions become inactive, the ALTER SYSTEM QUIESCE 
RESTRICTED statement completes, and the database is in a quiesced state. In an 
Oracle Real Application Clusters environment, this statement affects all instances, not 
just the one that issues the statement. 

TheALTER SYSTEM QUIESCE RESTRICTED statement may wait a long time for 
active sessions to become inactive. You can determine the sessions that are blocking 
the quiesce operation bv querving the VSBL0CKING_QUIE3CE view. This view 
returns onlv a single column: SID (Session ID). You can join it with VS SESSION to get 
more information about the session, as shown in the foUowing example: 

select bl.sid, uaer, osuaer, type, program 
from vSblockiiig_qiiiesce 1)1, vSsession ee 

where bl.sid = se.sid; 

See Oracle Database Reference for details on these view^. 

If you interrupt the request to quiesce the database, or if your session terminates 
abnormally before all active sessions are quiesced, then Oracle Database automatically 
reverses any partial effects of the statement. 

For queries that are carried out bv successive multiple Oracle Call Interface (OCI) 
fetches, the ALTER SYSTEM QUIESCE RESTRICTED statement does not wait for all 
fetches to finish. It only waits for the current fetch to finish. 

For both dedicated and shared server connections, all non-DBA logins after this 
statement is issued are queued bv the Database Resource Manager, and are not 
aUowed to proceed. To the user, it appears as if the login is hung. The login will 
resume when the database is unquiesced. 

The database remains in the quiesced state even if the session that issued the statement 
exits. A DBA must log in to the database to issue the statement that specifically 
unquiesces the database. 



Note: You cannot perform a cold backup when the database is in 
the quiesced state, because Oracle Database background processes 
mav still perform updates for internal purposes even while the 
database is quiesced. In addition, the file headers of online datafiles 
continue to appear to be accessible. They do not look the same as if 
a clean shutdown had been performed. However, vou can still take 
online backups while the database is in a quiesced state. 
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Restoring the System to Normal Operation 

The following statement restores the database to normal operation: 

ALTER SYSTEM UNQUIESCE; 

All non-DBA activit}' is allowed to proceed. In an Oracle Real Application Clusters 
environment, this statement is not required to be issued from the same session, or 
even the same instance, as that which quiesced the database. If the session issuing the 
ALTER SYSTEM UNQUIESCE statement terminates abnormally, then the Oracle 
Database server ensures that the unquiesce operation completes. 



Viewing the Quiesce State of an instance 

You can quer}' the ACTIVE_STATE column of the VS INSTANCE view to see the current 
state of an instance. The column values has one of these values; 

■ NORMAL: Normal unquiesced state, 

■ QUIESCING: Being quiesced, but some non-DBA sessions are still active. 

■ QUIESCED: Quiesced; no non-DBA sessions are active or allowed. 

Suspending and Resuming a Database 

The ALTER SYSTEM SUSPEND statement halts all input and output (I/O) to datafiles 
(file header and file data) and control files. The suspended state lets you back up a 
database without I/O interference. When the database is suspended all preexisting 
I/O operations are allowed to complete and anv new database accesses are placed in a 
queued state. 

The suspend command is not specific to an instance. In an Oracle Real Application 
Clusters environment, when you issue the suspend command on one system, internal 
locking mechanisms propagate the halt request across instances, thereby quiescing all 
active instances in a given cluster However, if someone starts a new instance another 
instance is being suspended, the new instance will not be suspended. 

Use the ALTER SYSTEM RESUME statement to resume normal database operations. 
The SUSPEND and RESUME commands can be issued from different instances. For 
example, if instances 1, 2, and 3 are running, and you issue an ALTER SYSTEM 
SUSPEND statement from instance 1, then you can issue a RESUME statement from 
instance 1, 2, or 3 with the same effect. 

The suspend/resume feature is useful in systems that allow you to mirror a disk or file 
and then split the mirror, providing an alternative backup and restore solution. If you 
use a svstem that is unable to split a mirrored disk from an existing database while 
writes are occurring, then you can use the suspend/resume feature to facilitate the 
split. 

The suspend /resume feature is not a suitable substitute for normal shutdown 
operations, because copies of a suspended database can contain uncommitted updates. 



Caution: Do not use the alter SYSTEM SUSPEND statement as a 
substitute for placing a tablespace in hot backup mode. Precede any 
database suspend operation by an ALTER TABLESPACE BEGIN 
BACKUP statement 
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The following statements illustrate ALTER SYSTEM SUSPEND/RESUME usage. The 
V$INSTANCE view is queried to confirm database status. 

SQL> ALTER SYSTEM SUSPEND; 

System altered 

S2L> SELECT DATRBASE_STATUS FROM VSIMSTAHCE; 

DATABASE STATUS 



SUSPENDED 



SQL> ALTER SYSTEM RESUME; 

System altered 

SQL> SELECT DATRBASE_STATUS FROM VSINSTAHCE; 

DATABASE STATUS 



ACTIVE 



See Also: Oracle Database Backup and Recovery User's Guide for 
details about backing up a database using the database 
suspend/resume feature 
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Managing Processes 



In this chapter; 

About Dedicated and Shared Server Processes 
About Database Resident Connection Poohng 
Configuring Oracle Database for Shared Server 
Configuring Database Resident Connection Pooling 
About Oracle Database Background Processes 
Managing Processes for Parallel SQL Execution 
Managing Processes for External Procedures 
Terminating Sessions 
Process and Session Data Dictionary Views 

About Dedicated and Shared Server Processes 

Oracle Database creates server processes to handle the requests of user processes 
connected to an instance, A server process can be either of the following: 

■ A dedicated server process, which services onlv one user process 

■ A shared server process, which can service multiple user processes 

Your database is alvi'avs enabled to allow dedicated server processes, but vou must 
specifically configure and enable shared server bv setting one or more initialization 
parameters. 

Dedicated Server Processes 

Figure 4-1, "Oracle Database Dedicated Sen'er Processes" illustrates how^ dedicated 
server processes work. In this diagram tivo user processes are connected to the 
database through dedicated server processes. 

In general, it is better to be connected through a dispatcher and use a shared server 
process. This is illustrated in Figure 4—2, "Oracle Database Shared Server Processes". A 
shared server process can be more efficient because it keeps the number of processes 
required for the running instance low. 

In the following situations, however, users and administrators should explicitly 
connect to an instance using a dedicated server process: 

■ To submit a batch job (for example, when a job can allow Uttle or no idle time for 
the server process) 



Managing Processes 4-1 



Aboul Dedicated and Shared Server Processes 



■ To use Recovery Manager (RMAN) to back up, restore, or recover a database 

To request a dedicated sender connection wlien Oracle Dat.ibase is configured for 
shared server, users must connect using a net service name that is configured to use a 
dedicated server Specificallv, the net ser\'ice name vahie should include the 
SERVEE=DEDICATED clause in the connect descriptor. 

See Also: Oracle Database Net Services Administrator's Guide for 
more information about requesting a dedicated server connection 

Figure 4-1 Oracle Database Dedicated Server Processes 
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Shared Server Processes 



Consider an order entry system with dedicated server processes. A customer phones 
the order desk and places an order, and the clerk taking the call enters the order into 
the database. For most of the transaction, the clerk is on the telephone talking to the 
customer A server process is not needed during this time, so the server process 
dedicated to the clerk's user process remains idle. The system is slower for other clerks 
entering orders, because the idle server process is holding system resources. 

Shared server architecture eliminates the need for a dedicated ser\'er process for each 
connection (see Figure 4r-2). 



4-2 Oracle Database Administrator's Guide 



About Dedicaled and Shared Server Processes 



Figure 4-2 Oracle Database Shared Server Processes 
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In a shared server configuration, client user processes connect to a dispatcher. The 
dispatcher can support muhiple client connections concurrently. Each client 
connection is bound to a virtual circuit, which is a piece of shared memor}' used by 
the dispatcher for client database connection requests and replies. The dispatcher 
places a virtual circuit on a common queue when a request arrives. 

An idle shared server process picks up the virtual circuit from the common queue, 
services the request, and relinquishes the \'irtual circuit before attempting to retrieve 
another virtual circuit from the common queue. This approach enables a small pool of 
server processes to serve a large number of clients, A significant advantage of shared 
server architecture over the dedicated server model is the reduction of system 
resources, enabling the support of an increased number of users. 

For even better resource management, shared server can be configured for connection 
pooling. Connection pooling lets a dispatcher support more users by enabling the 
database server to time-out protocol connections and to use those connections to 
service an active session. Further, shared server can be configured for session 
multiplexing, which combines multiple sessions for transmission over a single 
network connection in order to conserve the operating system's resources. 
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Shared server architecture requires Oracle Net Services. User processes targeting the 
shared server must connect through Oracle Net Services, even if they are on the same 
machine as the Oracle Database instance. 

See Also: Oracle Database Nef Services Adminislrafor's Guide for 
more detailed information about shared server, including features 
such as connection pooling and session multiplexing 

About Database Resident Connection Pooling 

Database Resident Connection Pooling (DRCP) provides a connection pool in the 
database server for typical Web application usage scenarios where the application 
acquires a database connection, works on it for a relativelv short duration, and then 
releases it, DRCP pools "dedicated" servers, which is the equivalent of a sen'er 
foreground and a database session combined and henceforth are referred to as the 
"pooled" sen'ers. 

DRCP complements middle-tier connection pools that share connections between 
threads in a middle-tier process. In addition, DRCP enables sharing of database 
connections across middle-tier processes on the same middle-tier host and even across 
middle-tier hosts. This results in significant reduction in kev database resources 
needed to support a large number of client connections, therebv reducing the database 
tier memorv footprint and boosting the scalability of both middle-tier and database 
tiers. Having a pool of readily available servers also has the additional benefit of 
reducing the cost of creating and tearing down client connections. 

DRCP is especially relevant for architectures with multi-process single threaded 
application servers (such as PHP /Apache) that cannot perform middle-tier connection 
pooling. The database can still scale to tens of thousands of simultaneous connections 
with DRCP 

See Also: 

■ Oracle Call Interface Programmer's Guide 

■ Oracle Database Concepts 

When To Use Database Resident Connection Pooling 

Database resident connection pooling is useful when multiple clients access the 
database and when any of the following apply: 

■ A large number of client connections need to be supported with minimum 
memory usage. 

■ The client applications are similar and can share or reuse sessions. 

Applications are similar if they connect with the same database credentials and 
use the same schema, 

■ The client applications acquire a database connection, work on it for a relatively 
short duration, and then release it, 

■ Session affinit}' is not required across client requests, 

■ There are multiple processes and multiple hosts on the client side. 

Advantages of Database Resident Connection Pooling 

Using database resident connection pooling provides the following advantages: 

■ Enables resource sharing among multiple middle-tier client applications. 
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Improves scalability of dattifci.ises and applications by reducing resource usage. 



Differences Between Dedicated Servers, Shared Servers, and Database Resident 
Connection Pooling 

Table 4-1 lists the differences between dedicated servers, shared servers, and database 
resident connection pooling. 

Table 4-1 Differences Between Dedicated Servers, Shared Servers, and Database Resident Connection 
Pooling 



Dedicated Servers 



Shared Servers 



Database Resident Connection 
Pooling 



When a client request is received, d 
new server process and a session 
are created for the client. 



When the first request is received When the first request is received 
from a client, the Dispatcher process from a client, the Connection Broker 



Releasing database resources 
involves terminating the session 
and server process. 

Memory requirement is 

proportional to the number of 
server processes and sessions. There 
is one server and one session for 
each client. 

Session memory is allocated from. 
the PGA. 



places this request on a common 
queue. The request is picked up by 
an available shared server process. 
The Dispatcher process then 
manages the communication 
between the client and the shared 
server process. 



Releasing database resources 
involves termmating the session. 



Memory requirement is 
proportional to the sum of the 
shared servers and sessions. There 
is one session for each client. 



Session memory is allocated from 
the SGA. 



picks an available pooled server and 
hands off the client connection to 
the pooled server 

If no pooled servers are available, 
the Connection Broker creates one. 
If the pool has reached its maximum 
size, the client request is placed on 
the wait queue until a pooled server 
is available. 

Releasing database resources 
involves releasing the pooled server 
to the pool. 

Memory requirement is 
proportional to the number of 
pooled servers and their sessions. 
Tliere is one session for each pooled 
server. 

Session memory is allocated from 
the PGA. 



Example of Memory Usage for Dedicated Server, Shared Server, and Database 
Resident Connection Pooling 

Consider an application in which the memory required for each session is 400 KB and 
the memorv required for each server process is 4 MB. The pool size is 100 and the 
nun\ber of shared servers used is 100. 

If there are 5000 client connections, the memorv used bv each configuration is as 
follows: 

■ Dedicated Server 

Memory used = 5000 X (400 KB + 4 MB) = 22 GB 

■ Shared Server 

Memory used = 5000 X 400 KB + 100 X 4 MB = 2.5 GB 
Out of the 2.5 GB, 2 GB is allocated from the SGA. 

■ Database Resident Connection Pooling 

Memory used = 100 X (400 KB + 4 MB) + (5000 X 35KB)= 615 MB 
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Restrictions on Using Database Resident Connection Pooling 

You cannot perform the iollowing activities witti pooled sen'ers: 

■ Shut down the database. 

■ Stop the database resident coruiection pool. 

■ Change the password for the connected user. 

■ Use shared database links to connect to a database resident connection pool that is 
on a different instance. 

■ Use all Advanced Security Option (ASO) options such as encryption, certificates, 
and so on. 

■ Use migratable sessions on the server side directly by using the OCI_MIGRATE 
option or indirectly via OCIConnectionPool. 

DDL statements that pertain to database users in the pool need to be performed 
carefully, as the pre-DDL sessions in the pool can still be given to clients post-DDL. 
For example, while dropping users, ensure that there are no sessions of that user in the 
pool and no connections to the Broker that were authenticated as that user 

Sessions with explicit roles enabled, that are released to the pool, can be later handed 
out to connections (of the same user) that need the default logon role. Avoid releasing 
sessions with explicit roles, and instead terminate them. 

Configuring Oracle Database for Shared Server 

Shared memor}' resources are preconfigured to allow the enabling of shared server at 
run time. You need not configure it bv specifying parameters in your initialization 
parameter file, but you can do so if that better suits your environment. You can start 
dispatchers and shared server processes (shared servers) dynamically using the ALTEH 
SYSTEM statement. 

This section discusses how to enable shared server and how to set or alter shared 
server initialization parameters. It contains the following topics: 

■ Initialization Parameters for Shared Ser\'er 

■ Enabhng Shared Server 

■ Configuring Dispatchers 

■ Shared Server Data Dictionary Views 

See Also: Orach Database SQL Language Kefcrciia: for further 
information about the ALTER SYSTEM statement 

Initialization Parameters for Shared Server 

The following initialization parameters control shared server operation: 

■ SHARED_SERVERS: Specifies the initial number of shared servers to start and the 
minimum number of shared servers to keep. This is the only required parameter 
for using shared servers. 

■ MAX_SHARED_ SERVERS: Specifies the maximum number of shared servers that 
can run simultaneously. 

■ SHARED_SERVER_SESSIONS: Specifies the total number of shared server user 
sessions that can run simultaneously. Setting this parameter enables you to reserve 
user sessions for dedicated servers. 
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DISPATCHERS: Configures dispatcher processes in the shared server architecture, 

MAX_DISPATCHERS: Specifies the maximum number of dispatcher processes that 
can run simultaneously. This parameter can be ignored for now. It will only be 
useful in a future release when the number of dispatchers is auto-tuned according 
to the niunber of concurrent connections. 

CIRCUITS: Specifies the total number of virtual circuits that are available for 
inbound and outbound netivork sessions. 

See Also: Oracle Database Referenee for more information about 
these initialization parameters 



Enabling Shared Server 



Shared server is enabled bv setting the SHARED_SERVERS initialization parameter to a 
value greater than 0. The other shared server initialization parameters need not be set. 
Because shared server requires at least one dispatcher in order to work, a dispatcher is 
brought up even if no dispatcher has been configured. Dispatchers are discussed in 
"Configuring Dispatchers" on page 4-9. 

Shared server can be started dynamically by setting the SHARED_SERVERS parameter 
to a nonzero value with the ALTER SYSTEM statement, or SHARED_SERVERS can be 
included at database startup in the initialization parameter file. If SHARED_SERVERS is 
not included in the initialization parameter file, or is included but is set to 0, then 
shared server is not enabled at database startup. 

Note: For backward compatibility, if SHARED_SERVERS is not 
included in the initialization parameter file at database startup, but 
DISPATCHERS is included and it specifies at least one dispatcher, 
shared server is enabled. In this case, the default for 

SHARED_SERVERS is 1. 

However, if neither SHARED_SERVERS nor DISPATCHERS is 
included in the initialization file, vou cannot start shared server 
after the instance is brought up by just altering the DISPATCHERS 
parameter. You must specifically alter SHARED_SERVERS to a 
nonzero value to start shared server 



Determining a Vaiue for SHARED_SERVERS 

The SHARED_SERVERS initialization parameter specifies the minimum number of 
shared servers that vou want created when the instance is started. After instance 
startup, Oracle Database can dynamically adjust the number of shared servers based 
on how busy existing shared servers are and the length of the request queue. 

In typical systems, the number of shared servers stabilizes at a ratio of one shared 
server for every ten connections. For OLTP apphcations, when the rate of requests is 
low, or when the ratio of server usage to request is low, the connections- to- servers 
ratio could be higher In contrast, in applications where the rate of requests is high or 
the server usage-to-request ratio is high, the connections- to-server ratio could be 
lower. 

The PMON (process monitor) background process cannot terminate shared servers 
below the value specified by SHARED_SERVERS. Therefore, you can use this 
parameter to stabilize the load and minimize strain on the system bv preventing 
PMON from terminating and then restarting shared servers because of coincidental 
iluctuations in load. 
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If voii know the average load on vour system, voii can set SHARED_SERVERS to an 
optimal value. The following example shows how you can use this parameter: 

Assume a database is being used by a telemarketing center staffed by 1000 agents. On 
average, each agent spends 90''u of the time talking to customers and onlv 10% of the 
time looking up and updating records. To keep the shared ser\'ers from being 
terminated as agents talk to customers and then spawned again as agents access the 
database, a DBA specifies that the optimal number of shared ser\'ers is 100. 

However, not all work shifts are staffed at the same level. On the night shift, only 200 
agents are needed. Since SHARED_SERVERS is a dynamic parameter, a DBA reduces 
the number of shared servers to 20 at night, thus allowing resources to be freed up for 
other tasks such as batch jobs. 

Decreasing the Number of Shared Server Processes 

You can decrease the minimum number of shared sen,'ers that must be kept active by 
dynamically setting the SHARED_SERVERS parameter to a lower value. Thereafter, 
until the number of shared sen,'ers is decreased to the value of the SHARED_ SERVERS 
parameter, anv shared servers that become inactive are marked bv PMON for 
termination. 

The following statement reduces the number of shared servers: 

ALTER SYSTEM SET SHAHED.SERVERS = 5; 

Setting SHARED_ SERVERS to disables shared ser\'er. For more information, please 
refer to "Disabhng Shared Sen'ers" on page 4-14. 

Limiting the Number of Shared Server Processes 

TheMAX_SHARED_SERVERS parameter specifies the maximum number of shared 
servers that can be automaticallv created bv PMON. It has no default value. If no value 
is specified, then PMON starts as many shared servers as is required bv the load, 
subject to these limitations; 

■ The process limit (set by the PROCESSES initialization parameter) 

■ A minimum number of free process slots (at least one-eighth of the total process 
slots, or two slots if PROCESSES is set to less than 24) 

■ Svstem resources 



Note: On Windows NT, take caie when setting 
MAX_SHARED_SERVERS to a high value, because each server is a 
thread in a common process. 



The value of SHARED_SERVERS overrides the value of MAX_SHARED_SERVERS. 
Therefore, you can force PMON to start more shared servers than the 
MAX_SHARED_SERVERS value by setting SHARED_SERVERS to a value higher than 
MAX_SHARED_ SERVERS. You can subsequently place a new upper limit on the 
number of shared servers by dynamically altering the MAX_SHARED_ SERVERS to a 
value higher than SHARED_SERVERS. 

The primar;' reason to limit the number of shared servers is to reserve resources, such 
as memory and CPU time, for other processes. For example, consider the case of the 
telemarketing center discussed previously: 

The DBA wants to reserve two thirds of the resources for batch jobs at night He sets 
MAX_SHARED_SERVERS to less than one third of the maximum number of processes 
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(processes). Bv doing so, the DBA ensures that even if all agents happen to access 
the database at the same time, batch jobs can connect to dedicated servers without 
having to wait for the shared servers to be brought down after processing agents' 
requests. 

Another reason to limit the number of shared servers is to prevent the concurrent run 
of too many server processes from slowing down the system due to heavy swapping, 
although PROCESSES can serve as the upper bound for this rather than 

MAX_SHAEED_SERVERS. 

Still other reasons to limit the number of shared servers are testing, debugging, 
performance analvsis. and tuning. For example, to see how many shared servers are 
needed to efficientlv support a certain user community', you can vary 
MAX_SHARED_SERVERS from a verv small number upward until no delay in response 
time is noticed bv the users. 

Limiting the Number of Shared Server Sessions 

The 3HARED_SERVER_SESSI0NS initialization parameter specifies the maximum 
number of concurrent shared server user sessions. Setting this parameter, which is a 
dynamic parameter, lets vou reser\'e database sessions for dedicated servers. This in 
turn ensures that administrative tasks that require dedicated servers, such as backing 
up or recovering the database, are not preempted by shared server sessions. 

This parameter has no default value. If it is not specified, the system can create shared 
server sessions as needed, limited by the SESSIONS initialization parameter 

Protecting Shared lUlemory 

The CIRCUITS parameter sets a maximum limit on the number of virtual circuits that 
can be created in shared memor\'. This parameter has no default. If it is not specified, 
then the system can create circuits as needed, limited bv the DISPATCHERS 
initialization parameter and system resources. 



Configuring Dispatchers 



The DISPATCHERS initialization parameter configures dispatcher processes in the 
shared server architecture. At least one dispatcher process is required for shared 
server to work. If vou do not specify a dispatcher, but vou enable shared ser\'er by 
setting SHARED_SERVER to a nonzero value, then bv default Oracle Database creates 
one dispatcher for the TCP protocol. The equivalent DISPATCHERS explicit setting of 
the initialization parameter for this configuration is: 

dispatchers=" (PR0TOC0L=tcp) " 

You can configure more dispatchers, using the DISPATCHERS initialization parameter, 
if either of the following conditions apply: 

■ You need to configure a protocol other than TCP/IP. You configure a protocol 
address with one of the following attributes of the DISPATCHERS parameter: 

- ADDRESS 

- DESCRIPTION 

- PROTOCOL 

■ You want to configure one or more of the optional dispatcher attributes: 

- DISPATCHERS 

- CONNECTIONS 
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- SESSIONS 

- TICKS 

- LISTENER 

- MULTIPLEX 

- POOL 

- SERVICE 



Note: Database Configuration Assistant helps vou configure tliis 
parameter. 



DISPATCHERS Initialization Parameter Attributes 

Tliis section provides brief descriptions of tiie attributes tiiat can be specified with the 
DISPATCHERS initialization parameter. 

A protocol address is required and is specified using one or more of the following 
attributes; 



Attribute 



Description 



ADDRESS 



DESCRIPTIOH 



PROTOCOL 



Specify the network protocol address of the end point on which 
tlie dispiitchers listen. 

Specify the network description of the endpoint on which the 
dispatchers listen, including the network protocol address. The 
syntax is aa follows: 

(DESCHIPTIDN= (ADDHESS=. . . 1 ) 

Specify the network protocol for which the dispatcher 
generates a listening endpoint. For example: 

(PROTOCOL- tcp) 

See the Oracle Database Net Serakes Reference for further 
information about protocol address syntax. 



The following attribute specifies how many dispatchers this configuration should 
have. It is optional and defaults to 1, 



Attribute 



Description 



DISPATCHERS 



Specify the initial number of dispatchers to start 



The foliowing attributes tell the instance about the network attributes of each 
dispatcher of this configuration. Thev are all optional. 



Attribute 



Description 



CONHECTIOHS 



SESSIONS 



TICKS 



Specify the maximum number of network connections to allow 
for each dispatcher 

Specify the maximum number of network sessions to allow for 
each dispatcher. 

Specify the duration of a TICK in seconds. A TICK is a unit of 
tim.e in terms of which the connection pool timeout can be 

specified. Used for connection pooling. 
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Attribute Description 



LISTEHER Specify an alias name for the listeners with which the PMON 

process registers dispatcher information. Set the ahas to a 
name that is resolved through a naming method. 

MULTIPLEX Used to enable the Oracle Connection Manager session 

multiplexing feature. 

POOL Used to enable connection pooling. 

SERVICE Specif}' the service names the dispatchers register with the 

listeners 



You can specify either an entire attribute name a substring consisting of at least the 
first three characters. For example, you can specify SESSI0NS=3. SES=3, SESS=3, or 
SESSI = 3, and so forth. 

See Also: Oracle Dalabase Reforcncc for more detailed descriptions 
of the attributes of the DISPATCHERS initialization parameter 

Determining the Number of Dispatchers 

Once you know the number of possible connections for each process for the operating 
svstem, calculate the initial number of dispatchers to create during instance startup, 
for each network protocol, using the following formula: 

Number oE dispatchers = 

CEIL { max. concurrent Eessions / connections for each dispatcher } 

CEIL returns the result roundest up to the next whole integer 

For example, assume a svstem that can support 970 connections for each process, and 
that has: 

■ A maximum of 4000 sessions concurrently connected through TCP/IP and 

■ A maximum of 2,500 sessions concurrently connected through TCP/IP with SSL 

The DISPATCHERS attribute for TCP/IP should be set to a minimum of five 
dispatchers (4000 / 970), and for TCP/IP with SSL three dispatchers (2500 / 970: 

DI3PATCHERS=' (PROT=tcp) {DISP=5) ' , ' (PROT-tcps) {DISP=3) ' 

Depending on performance, you may need to adjust the number of dispatchers. 

Setting the initiai Number of Dispatchers 

You can specify multiple dispatcher configurations by setting DISPATCHERS to a 
comma separated list of strings, or by specifying multiple DISPATCHERS parameters 
in the initialization file. If you specify DI SPATCHERS multiple times, the lines must be 
adjacent to each other in the initialization parameter file. Internally, Oracle Database 
assigns an INDEX value (beginning with zero) to each DI SPATCHERS parameter You 
can later refer to that DISPATCHERS parameter in an ALTER SYSTEM statement by its 
index number 

Some examples of setting the DISPATCHERS initialization parameter follow. 

Example: Typical This is a typical example of setting the DISPATCHERS initialization 
parameter, 

DISPATCHERS=" (PROTOCOL=TCP) {DISPATCHERS=2] " 
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Example: Forcing the IP Address Used lor Dispatchers The following hypothetical 
example will create two dispatchers that will listen on the specified IP address. The 
address must be a valid IP address for the host that the instance is on. (The host may 
be configured with multiple IP addresses.) 

DISPATCHERS=" {ADDRES3= (PROTOCOL=TCP) (H0ST=144 . 25 .16 .201) ) {DISPATCHERS=2) " 

Example: Forcing the Port Used by Dispatchers To force the dispatchers to use a 
specific port as the listening endpoint, add the PORT attribute as follows: 

DI3PATCHERS=" {ADDRES3= (PROTOCOL=TCP) (PORT=5000) } " 
DI3PATCHERS=" {ADDRES3= (PROTOCOL=TCP) (PORT=5001) )" 

Altering the Number of Dispatchers 

You can control the number of dispatcher processes in the instance. Unlike the number 
of shared servers, the number of dispatchers does not change automatically. You 
change the number of dispatchers explicitly with the ALTER SYSTEM statement. In 
this release of Oracle Database, you can increase the number of dispatchers to more 
than the limit specified by theMAX_DISPATCHERS parameter It is planned that 
MAX_DISPATCHERS will be taken into consideration in a future release. 

Monitor the following views to determine the load on the dispatcher processes: 

■ VSQUEUE 

■ VSDISPATCHER 

■ V$DISPATCHER_RATE 

See Also: Oracle Database Performance Tuning Guide for 
information about monitoring these views to determine dispatcher 
load and performance 

If these \'iews indicate that the load on the dispatcher processes is consistently high, 
then performance may be improved bv starting additional dispatcher processes to 
route user requests. In contrast, if the load on dispatchers is consistently low, reducing 
the number of dispatchers mav improve performance. 

To dynamically alter the number of dispatchers when the instance is running, use the 
ALTER SYSTEM statement to modify the DISPATCHERS attribute setting for an 
existing dispatcher configuration. You can also add new dispatcher configurations to 
start dispatchers with different network attributes. 

When you reduce the number of dispatchers for a particular dispatcher configuration, 
the dispatchers are not immediately removed. Rather, as users disconnect, Oracle 
Database terminates dispatchers down to the limit you specify in DISPATCHERS, 

For example, suppose the instance was started with this DISPATCHERS setting in the 
initialization parameter file: 

DI3PATCHER3=' {PROT=tcp) {DISP=2) ' , ' (PROT=tcps) {DISP=2) ' 

To increase the number of dispatchers for the TCP/IP protocol from 2 to 3, and 
decrease the number of dispatchers for the TCP/IP with SSL protocol from 2 to 1, you 
can issue the following statement: 

ALTER SYSTEM SET DISPATCHERS = ' (INDEX=0) (DISP=3) ' , ' (INDES=1) (DISP=1) ' ; 

or 

ALTER SYSTEM SET DISPATCHERS = ' [PROT=tcp) {DISP=3) ' , ' (PROT-tcps) {DISP=1) ' ; 
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Note: You need not specify {DISP=l). It is optional because 1 is 
the default value for the DISPATCHERS parameter. 



If fewer than three dispatcher processes currently exist for TCP/IP, the database 
creates new ones. If more than one dispatcher process currently exists for TCP/IP with 
SSL, then the database terminates the extra ones as the connected users disconnect 

Suppose that instead of changing the number of dispatcher processes for the TCP/IP 
protocol, you want to add another TCP/IP dispatcher that supports connection 
pooling. You can do so by entering the following statement: 

ALTER SYSTEM SET DISPATCHERS = ' [IHDEX=2) (PROT=tcp) (POOL=on) ' ; 

The INDEX attribute is needed to add the new dispatcher configuration. If vou omit 
(INDEX=2) in the preceding statement, then the TCP/IP dispatcher configuration at 
INDEX will be changed to support connection pooling, and the number of 
dispatchers for that configuration will be reduced to 1, which is the default when the 
number of dispatchers (attribute DISPATCHERS) is not specified. 

Notes on Altering Dispatchers 

■ The INDEX keyword can be used to identify which dispatcher configuration to 
modify. If vou do not specify INDEX, then the first dispatcher configuration 
matching the DESCRIPTION, ADDRESS, or PROTOCOL specified will be modified. 
If no match is found among the existing dispatcher configurations, then a new 
dispatcher will be added. 

■ The INDEX value can range from to n-1, where n is the current number of 
dispatcher configurations. If your ALTER SYSTEM statement specifies an INDEX 
value equal to n, where n is the current number of dispatcher configurations, a 
new dispatcher configuration will be added. 

■ To see the values of the current dispatcher configurations—that is, the number of 
dispatchers, whether connection pooling is on, and so forth— query the 
VSDISPATCHER_CONFIG dynamic performance view. To see which dispatcher 
configuration a dispatcher is associated with, query the CONF_INDX column of the 

VSDI SPATCHER view, 

■ When you change the DESCRIPTION, ADDRESS, PROTOCOL, CONNECTIONS, 
TICKS, MULTIPLEX, and POOL attributes of a dispatcher configuration, the change 
does not take effect for existing dispatchers but only for new dispatchers. 
Therefore, in order for the change to be effective for all dispatchers associated with 
a configuration, you must forcibly kill existing dispatchers after altering the 
DISPATCHERS parameter, and let the database start new ones in their place with 
the newly specified properties. 

The attributes LI STENER and SERVICES are not subject to the same constraint. 
They apply to existing dispatchers associated with the modified configuration. 
Attribute SESSIONS applies to existing dispatchers only if its value is reduced. 
However, if its value is increased, it is applied only to newly started dispatchers. 

Shutting Down Specific Dispatcher Processes 

With the ALTER SYSTEM statement, you leave it up to the database to determine 
which dispatchers to shut down to reduce the number of dispatchers. Alternatively, it 
is possible to shut down specific dispatcher processes. To identify the name of the 
specific dispatcher process to shut down, use the VSDISPATCHER dynamic 
performance view. 
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SELECT HME, NETOORK FROM VS DISPATCHER; 

Each dispatcher is uniquely identified by a name of the form Dnnn. 
To shut down dispatcher DO 2, issue the following statement: 

ALTER SYSTEM SHUTDOWN IMMEDIATE 'D002 ' ; 

The IMMEDIATE keyword stops the dispatcher from accepting new connections and 
the database immediatelv terminates all existing connections through that dispatcher 
After all sessions are cleaned up, the dispatcher process shuts down. If IMMEDIATE 
were not specified, the dispatcher would wait until all of its users disconnected and all 
of its connections terminated before shutting down. 

Disabling Shared Servers 

You disable shared server by setting SHARED_SERVERS to 0, No new client can 
connect in shared mode. However, when you set SHARED_SERVERS to 0, Oracle 
Database retains some shared servers until all shared server connections are closed. 
The number of shared servers retained is either the number specified bv the preceding 
setting of SHARED_SERVERS or the value of the MAX_SHARED_SERVERS parameter, 
whichever is smaller. If both SHARED_SERVERS and MAX_SHARED_ SERVERS are set 
to 0, then all shared servers will terminate and requests from remaining shared server 
clients will be queued until the value of SHARED_SERVERS or MAX_SHARED_SERVERS 
is raised again. 

To terminate dispatchers once all shared server clients disconnect, enter this statement: 

ALTER SYSTEM SET DISPATCHERS = ' ' : 



Shared Server Data Dictionary Views 



The following views are useful for obtaining information about vour shared server 
configuration and for monitoring performance. 



View 


Description 


V$ DISPATCHER 


Provides information on the dispatcher processes, 
including name, network address, status, various usage 
statistics, and index number 


VS DIS PATCHER_CONFIG 


Provides configuration information about the dispatchers. 


VS DIS PATCHER_RATE 


Provides rate statistics for the dispatcher processes. 




Contains information on the shared server message 
queues. 


VSQOEUE 


VS SHAHED_SERVER 


Contains information on the shared servers. 


VS CIRCUIT 


Contains information about virtual circuits, which are 
user connections to the database through dispatchers and 
servers. 


VS SHARED_SERVER_MONIT0R 


Contains information for tuning shared server 


VSSGA 


Contains size information about various system global 

area (SGA) groups. Maybe useful when tuning shared 
server 


VSSGASTAT 


Contains detailed statistical information about the SGA, 
useful for tuning. 


VS SHARED_P0OL_RESERVED 


Lists statistics to help tune the reserved pool and space 
within the shared pool. 
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See Also: 

■ Oracle Database Reference for detailed descriptions of these 
views 

■ Oracle Database Perjbrmatice Timing Guide for specific 
information about monitoring and tuning shared server 

Configuring Database Resident Connection Pooling 

The database server is preconfigured to aUow database resident connection pooling. 
However, you must explicitly enable this feature by starting the connection pool. 

This section contains the following topics: 

■ Enabhng Database Resident Connection Pooling 

■ Configuring the Coruiection Pool for Database Resident Connection Pooling 

■ Data Dictionary Views for Database Resident Connection Pooling 

Enabling Database Resident Connection Pooling 

Oracle Database includes a default connection pool called 

SYS_DEFAULT_c;ONNSCTION_POOL. By default, this pool is created, but not started. 
To enable database resident connection pooling, vou must explicitly start the 
connection pool. 

To enable database resident connection pooling: 

1 . Start the database resident coruiection pool, as described in "Starting the Database 
Resident Connection Pool" on page 4-15. 

2. Route the client connection requests to the connection pool, as described in 
"Routing Client Connection Requests to the Connection Pool" on page 4-15. 

Starting the Database Resident Connection Pool 
To start the connection pool, use the following steps: 

1. Start SQL'Plus and connect to the database as the SYS user 

2. Issue the following command: 

SQL> EXECUTE DBHS_C0MMECTIOH_PO0L.START_PO0L [ ) ; 

Once started, the connection pool remains in this state until it is explicitiv stopped. 
The connection pool is automatically restarted when the database instance is restarted 
a the pool was active at the time of instance shutdown. 

In an Oracle Real Application Clusters (RAC) environment, vou can use any instance 
to manage the connection pool, Anv changes you make to the pool configuration are 
applicable on all Oracle RAC instances. 

Routing Client Connection Requests to the Connection Pool 

In the client application, the connect string must specify the connect tvpe as POOLED, 

The following example shows an easy connect string that enables clients to connect to 
a database resident connection pool: 

□raclehos t. company .com: 1521/bookE .company .com: POOLED 
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The following example shows a TNS connect descriptor that enables clients to connect 
to a database resident connection pool: 

(DESCRIPn:ON= (ADDHESS= (PROTOCOL=tcp) ( HOST=niyhQS t ] 

(PORT=1521}) {CONlIECT_DATA=(SERVICE_MME=sales] 
(SERVER=POOLED)) ) 

Disabling Database Resident Connection Pooling 

To disable database resident connection pooling, you must explicitly stop the 
connection pool. Use the following steps: 

1. Start SQL'Plus and connect to the database as the SYS user, 

2. Issue the following command: 

SQL> EXECUTE DBHS_C0HKECTIOH_PO0L.ST0P_P0OL( ) ; 

See Also: Oracle Database PL/SQL Packages and Types Reference for 
more information on the DBMS_CONNECTION_POOL package. 



Note: The operation of disabling the database resident connection 
pool can be completed only when all client requests that have been 
handed off to a server are completed. 



Configuring the Connection Pool for Database Resident Connection Pooling 

The connection pool is configured using default parameter values. You can use the 
procedures in the DBMS_CONNECTION_POOL package to configure the connection pool 
according to vour usage. In an Oracle Real Application Clusters (RAC) environment, 
the configuration parameters are applicable to each Oracle RAC instance. 

Table 4r-2 lists the parameters that vou can configure for the connection pool. 



Table 4-2 Configuration Parameters for Database Resident Connection Pooling 



Parameter Name 



Description 



MINSIZE The minimum number of pooled servers in the pool. The 

default value is 4, 

MAXSIZE The maximum number of pooled servers in the pool. The 

default value is 40. 

IHCRSIZE The number of pooled servers by which the pool is 

incremented if servers are unavailable when a client 
application request is received. The default value is 3, 

SESSION_CACHED_CURSORS The number of session cursors to cache in each pooled server 

session. The default value is 20, 



IHACTrVITY TIMEOUT 



MAX THItJK TIME 



The maximum time, in seconds, the pooled server can stay idle 
in the pool. After this time, the server is terminated. Tlie 
default value is 300. 

This parameter does not apply if the pool is at MINSIZE, 

The maximum time of inactivitv, in seconds, for a client after it 
obtains a pooled server from the pool. After obtaining a pooled 
server from the pool, if the client application does not issue a 
database call for the time specified by MAX_THIHK_TIME, the 
pooled server is freed and the client connection is terminated. 
The default value is 30, 



4-16 Oracle Dalabase Administrator's Guide 



Conliguring Database Residenl Connection Pooling 



Table 4-2 (Cont.) Configuration Parameters for Database Resident Connection Pooling 



Parameter Name Description 



MftX_DSE_SESSIOH The number of times a pooled server can be taken and released 

to the pool. The default value is 5000. 

MAX_LIFETIME_SESSIOH The time, in seconds, to live for a pooled server in the pool. 

The default value is 3600 

NUM_CBROK The number of Connection Brokers that are created to handle 

client requests. The default value is 1. 

Creating multiple Connection Broker processes helps 
distribute the load of chent connection requests if there are a 
large number of client applications. 

MAXC0HN_CBROK The maxim."um number of connections that each Connection 

Broker can handle. 

The default value is 40000. But if the maximum connections 
allowed by the platform on which the database is installed is 
lesser than the default value, this value overrides the value set 
using MaXC0HN_CBROK. 

Set the per-process file descriptor limit of the operating system 
sufficiently high so that it supports the number of connections 
specified byMAXCOHH_CBROK. 

Using the CONFIGURE_POOL Procedure 

The COHFIGURE_POOL procedure of the DBMS_CONNECTION_POOL package enables 
you to configure the connection pool with advanced options. This procedure is usually 
used when you need to modify all the parameters of the connection pool. 

Using the ALTER_PARAM Procedure 

The ALTER_PARAM procedure of the DBMS_CONNECTION_POOL package enables you 
to alter a specific configuration parameter without affecting other parameters. 

For example, the following command changes the minimum number of pooled sen'ers 
used: 

SQL> EXECUTE DBMS_C0MNECTIOH_P00L.ALTER_PAMM { ' ' , 'MIH3IZE' , ' 10 ' ) ; 

The following example, changes the maximum number of coruiections that each 
connection broker can handle to 50000, 

SQL> EXECUTE DBMS_CONNECTIOH_POOL.ALTER_PAEAH {' ', ' MftXCOM_CBROK ' , '50000' ) ; 

Before vou execute this command, ensure that the maximum number of connections 
allowed by the platform on which your database is installed is not less than the value 
you set for MAXCOWN_CBROK. 

For example, in Linux, the following entry in the /etc/ security/ limits . conf file 
indicates that the maximum number of connections allowed for the user test_user 
is 30000, 

test_UEer HftHD NOFILE 30000 

To set the maximum number of connections that each connection broker can allow to 
50000, first change the value in the limits .conf file to a value not less than 50000. 

Restoring the Connection Pool Default Settings 

If you have made changes to the connection pool parameters, but you want to revert to 
the default pool settings, use the RESTORE_DEFAULT procedure of the 
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DBMS_COWNECTIOW_POOL package. The cojnmand. to restore the connection pool to 
its default settings is: 

S2L> EXECUTE DBHS_C0HNECTION_PO0L.REST0HE_DEFA"0LTS { ) ; 

See Also: Oracle Database PL/SQL Packages and Types Reference for 
more iniormation on the DBMS_CONNECTION_POOL package. 

Data Dictionary Views for Database Resident Connection Pooling 

Table 4-3 lists the data dictionary views that provide inforination about database 
resident connection pooling. Use these views to obtain information about vour 
connection pool and to monitor the performance of database resident connection 
pooling. 

Table 4-3 Data Dictionary Views for Database Resident Connection Pooling 

View Description 

DBA_CPO0L_INF0 Conttiins inforiTiijtion about the connection pool such as the pool 

stdtus, the maximum and minimum number of connections, and 
timeout for idle sessions. 

VSCPOOL_STATS Contains pool statistics such as the number of session requests, 

number of times a session that matches the request was found in 
the pool, and total wait time for a session request. 

VSCP0OL_CC_STATS Contains connection class level statistics for the pool. 

See Also: Oracle Database Rejerence for more information about these 
views. 

About Oracle Database Background Processes 

To maximize performance and accommodate manv users, a multiprocess Oracle 
Database system uses background processes. Background processes consolidate 
functions that would otherwise be handled bv multiple database programs running 
for each user process. Background processes asvnchronouslv perform I/O and 
monitor other Oracle Database processes to provide increased parallelism for better 
performance and reliabilit\'. 

Table 4rA describes the basic Oracle Database background processes, manv of which 
are discussed in more detail elsewhere in this book. The use of additional database 
server features or options can cause more background processes to be present. For 
example, when vou use Advanced Queuing, the queue monitor (QMNi;) background 
process is present. When you specify the FILE_MAPPING initialization parameter for 
mapping datafiles to physical devices on a storage subsystem, then the FMON process 
is present. 
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Table 4-4 Oracle Database Background Processes 



Process Name 



Description 



Database writer (DBWn) 



Log writer (LGWE) 



Checkpoint (CKFT) 



System monitor (SMON) 



Process monitor (PMON) 



Archiver (ARCn) 



Recoverer (RECO) 



Dispatcher (Dunn) 



GloLial Cache Service 
(LMS) 



The database writer writes modified blocks from, the database buffer cache to the 
datafiles. Oracle Database allows a maximum of 20 database writer processes 
(DBWO-DBWO and DBWa-DBWj). The DB_WRITER_PROCESSES initialization 
parameter specifies the number of DBWii processes. The database selects an 
appropriate default setting for this initialization parameter or adjusts a user-specified 
setting based on the number of CPUs and the number of processor groups. 

For more information about setting the DB_WRITER_PR0CESSE3 initialization 
parameter, see the Oracle Dahibase Performance Tuning Guide. 

The log writer process writes redo log entries to disk. Redo log entries are generated 
in the redo log buffer of the system global area (SGA). LGWR writes the redo log 
entries sequentially into a redo log file. If the database has a multiplexed redo log, 
dien LGWR writes the redo log entries to a group of redo log files. See Chapter 10, 
"Managing fhe Redo Log" for information about the log writer process. 

At specific times, all modified database buffers in the system global area are written 
to the datafiles by DBWn. This event is called a checkpoint The checkpoint process is 
responsible for signalling DBWii at checkpoints and updating all the datafiles and 
control files of the database to indicate the most recent cheokpomt. 

The system monitor performs recovery when a failed instance starts iip again. In an 
Oracle Real Application Clusters database, the SMON process of one instance can 
perform instance recovery for other instances that have failed. SMON also cleans up 
temporary segments that are no longer in use and recovers dead transactions skipped 
during system failure and instance recovery because of file-read or offline errors. 
These transactions are eventually recovered by SMON when the table space or file is 
brought back online. 

The process monitor performs process recovery when a user process fails. PMON is 
responsible for cleaning up the cache and freeing resources that the process was 
using. PMON also checks on the dispatcher processes (described later in this table) 
and server processes and restarts them if they have failed. 

One or more archiver processes copy the redo log files to archival storage when they 
are full or a log switch occurs. Archiver processes are the subject of Chapter 11, 
"Managing Archived Redo Logs". 

The recoverer process is used to resolve distributed transactions that are pending 
because of a network or system failure in a distributed database. At timed intervals, 
the local RECO attempts to connect to remote databases and automatically complete 
the commit or rollback of the local portion of any pending distributed transactions. 
For inform.ation about this process and how to start it, see Chapter 33, "Managing 
Distributed Transactions". 

Dispatchers are optional background processes, present only when the shared server 
configuration is used. Shared server was discussed previously in "Configuring Oracle 
Database for Shared Server" on page 4-6. 

In an Oracle Real Application Clusters environment, this process manages resources 
and provides inter-instance resource control. 



See Also: Oracle DafnbiKe Concepts for more information about 
Oracle Database background processes 



Managing Processes for Parallel SQL Execution 



Note: The parallel execution feature described in this section is 
avaUable with the Oracle Database Enterprise Edition. 
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This section describes how to manage parallel processing of SQL statements. In this 
configuration Oracle Database can divide the work of processing an SQL statement 
among multiple parallel processes. 

The execution of many SQL statements can be parallelized. The degree of parallelism 
is the number of parallel execution servers that can be associated with a single 
operation. The degree of parallelism is determined by any of the following: 

■ A PARALLEL clause in a statement 

■ For objects referred to in a querv. the PARALLEL clause that was used when the 
object was created or altered 

■ A parallel hint inserted into the statement 

■ A default determined by the database 

An example of using pariiUel SQL execution is contained in "Parallelizing Table 
Creation" on page 18-11, 

The following topics are contained in this section: 

■ About Parallel Execution Servers 

■ Altering Parallel Execution for a Session 

See Also: 

■ Oracle Database Conayts for a description of parallel execution 

■ Orack' Database Performance Tuning Guide for information about 
using parallel hints 

About Parallel Execution Servers 

When an instance starts up, Oracle Database creates a pool of parallel execution 
servers which are available for any parallel operation. A process called the parallel 
execution coordinator dispatches the execution of a pool of parallel execution servers 
and coordinates the sending of results from all of these parallel execution servers back 
to the user. 

The parallel execution servers are enabled bv default, because bv default the value for 
PAEALLEL_MAX_SEEVEES initialization parameter is set >0, The processes are 
available for use by the various Oracle Database features that are capable of exploiting 
parallelism. Related initialization parameters are tuned bv the database for the 
majoritv of users, but vou can alter them as needed to suit vour environment For ease 
of tuning, some parameters can be altered dynamicalh'. 

Parallelism can be used bv a number of features, including transaction recovery, 
replication, and SQL execution. In the case of parallel SQL execution, the topic 
discussed in this book, parallel server processes remain associated with a statement 
throughout its execution phase. When the statement is completely processed, these 
processes become available to process other statements. 

See Also: Oracle Database Data Warehousing Guide for more 
information about using and tuning parallel execution, including 
parallel SQL execution 

Altering Parallel Execution for a Session 

You control parallel SQL execution for a session using the ALTER SESSION statement. 
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Disabling Paraliel SQL Execution 

You disable parallel SQL execution with an ALTER SESSION DISABLE PARALLEL 
DML I DDL I QUERY statement. All subsequent DML (INSERT, UPDATE, DELETE), DDL 
(CREATE, ALTER), or query (SELECT) operations are executed serially after such a 
statement is issued. They will be executed serially regardless of anv PARALLEL clause 
associated with the statement or parallel attribute associated with the table or indexes 
involved. 

The following statement disables parallel DDL operations: 

ALTER SES3I0H DISABLE PARALLEL DDL; 

Enabiing Parailei SQL Execution 

YouenableparallelSQLexecution with an ALTER SESSION ENABLE PARALLEL 
DML I DDL I QUERY statement. Subsequently, when a PARALLEL clause or parallel hint is 
associated with a statement, those DML, DDL, or quer}' statements will execute in 
parallel. By default, parallel execution is enabled for DDL and query statements. 

A DML statement can be parallelized onlv if you specifically issue an ALTER 
SESSION statement to enable parallel DML: 

ALTER SESSION ENABLE PARALLEL DML; 

Forcing Paraliei SQL Execution 

You can force paraUel execution of all subsequent DML, DDL, or query statements for 
whichparallelizationispossible with the ALTER SESSION FORCE PARALLEL 
DML I DDL I QUERY statement. Additionally you can force a specific degree of 
parallelism to be in effect, overriding any PARALLEL clause associated with 
subsequent statements. If vou do not specify a degree of parallelism in this statement, 
the default degree of parallelism is used. However, a degree of parallelism spiecified in 
a statement through a hint will override the degree being forced. 

The following statement forces parallel execution of subsequent statements and sets 
the overriding degree of parallelism to 5: 

ALTER SESSION FORCE PARALLEL DDL PARALLEL 5; 

Managing Processes for External Procedures 

External procedures are procedures written in one language that are called from 
another program in a different language. An example is a PL/SQL program calling 
one or more C routines that are required to perform special-purpose processing. 

These callable routines are stored in a dynamic link library (DLL), or a libunit in the 
case of a Java class method, and are registered with the base language. Oracle 
Database provides a special-purpose interface, the call specification (call spec), that 
enables users to call external procedures from other languages. 

To call an external procedure, an application alerts a network listener process, which 
in turn starts an external procedure agent. The default name of the agent is extproc, 
and this agent must reside on the same computer as the database server. Using the 
network connection established by the listener, the application passes to the external 
procedure agent the name of the DLL or libunit, the name of the external procedure, 
and anv relevant parameters. The external procedure agent then loads, DLL or libunit, 
runs the external procedure, and passes back to the application any values returned by 
the external procedure. 
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To control access to DLLs, the database administrator grants execute privileges on the 
appropriate DLLs to apphcation developers. The application developers write the 
externa! proceduies and grant execute privilege on specific external procedures to 
other users. 



Note: The external librar)' (DLL file) must be staticallv linked. In 
other words, it must not reference an;' external svmbols from other 
external libraries (DLL files). Oracle Database does not resolve such 
symbols, so they can cause your external procedure to fail. 



The enviroiunent for calling external procedures, consisting of toHnames . ora and 
listener . ora entries, is configured bv default during the installation of vour 
database. You may need to perform additional netivork configuration steps for a 
higher level of security. These steps are documented in the Oracle Database Nef Services 
Adiiiiiiisfralor's Guide. 

See Also: Oracle Database Advanced Application Developer's Guide 
for information about external procedures 



Terminating Sessions 



Sometimes it is necessar;' to terminate current user sessions. For example, you might 
want to perform an administrative operation and need to terminate all 
non-administrative sessions. This section describes the various aspects of terminating 
sessions, and contains the following topics: 

■ Identifying Which Session to Terminate 

■ Terminating an Active Session 

■ Terminating an Inactive Session 

When a session is terminated, anv active transactions of the session are rolled back, 
and resources held by the session (such as locks and memor\' areas) are immediately 
released and available to other sessions. 

You terminate a current session using the SQL statement ALTEH SYSTEM KILL 
SESSION. The following statement terminates the session whose system identifier is 7 
and serial number is 15: 

ALTER SYSTEM KILL SESSIOM '7.15'; 



Identifying Which Session to Terminate 



To identifv which session to terminate, specifv the session index number and serial 
number. To identify the svstem identifier (SID) and serial number of a session, query 
the V$ SESSION dynamic performance view. For example, the following query 
identifies all sessions for the user jward: 

SELECT SID, SERIALtt, STATUS 
FROM VSSESSION 
WHERE USERMAME = ' ^ARD ' ; 

SID SERIAL* STATUS 



7 15 ACTIVE 
13 63 INACTIVE 
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A session is ACTIVE when it is making a SQL call to Oracle Database. A session is 
INACTIVE if it is not making a SQL call to the database. 

See Also: Oracle Database Reference for a description of the status 
values for a session 

Terminating an Active Session 

If a user session is processing a transaction (ACTIVE status) when you terminate the 
session, the transaction is rolled back and the user immediately recei\'es the following 
message: 

OEA-00028: your session has been killed 

If, after receiving the ORA- D 2 B message, a user submits additional statements 
before reconnecting to the database, Oracle Database returns the following message: 

OEA-01012: not logged on 

An active session cannot be interrupted when it is performing neti\'ork I/O or rolling 
back a transaction. Such a session cannot be terminated until the operation completes. 
In this case, the session holds all resources until it is terminated. Additionally, the 
session that issues the ALTER SYSTEM statement to terminate a session waits up to 60 
seconds for the session to be terminated. If the operation that cannot be interrupted 
continues past one minute, the issuer of the ALTER SYSTEM statement receives a 
message indicating that the session has been marked to be terminated. A session 
marked to be terminated is indicated in VS SESSION with a status of KILLED and a 
server that is something other than PSEUDO. 



Terminating an Inactive Session 



If the session is not making a SQL call to Oracle Database (is INACTIVE) when it is 
terminated, the ORA- 2 8 message is not returned immediately. The message is not 
returned until the user subsequently attempts to use the terminated session. 

When an inactive session has been terminated, the STATUS of the session in the 
VSSESSION view is KILLED. The row for the terminated session is removed from 
VSSESSION after the user attempts to use the session again and receives the 
ORA- 2 B message. 

In the following example, an inactive session is terminated. First, VSSESSION is 
queried to identify the SID and SERIALtt of the session, and then the session is 
terminated, 

SELECT SID, SERIAL*, STATUS, SERVER 
FROM VSSESSIOH 
INHERE USERMAME = 'JWARD'; 

SID SERIAL* STATUS SERVER 



7 15 INACTIVE DEDICATED 
12 53 INACTIVE DEDICATED 
2 rows selected. 

ALTER SYSTEM KILL SE3SI0H '7,15'; 
Statement processed. 

SELECT SID, SERIALtt, STATUS, SERVER 
FROM VSSES3I0H 
I'fflERE USERMAME = 'JWARD'; 



Managing Processes 4-23 



Process and Session Data Dictionary Views 



SID 



SERIAL* STATUS 



SERVER 



7 15 KILLED PSEUDO 
12 53 INACTIVE DEDICATED 
2 rows selected. 



Process and Session Data Dictionary Views 



The following are the data dictionar}' views that can help you manage processes and 
sessions. 



View 


Description i 


VS PROCESS 


Contains information about the currently active processes 


VS SESSION 


Lists session information for each current session 


V$SESS_IO 


Contains I/O statistics for each user session 


VS SES S IOH_LOHG0PS 


Displays the status of various operations that run for longer 
than 6 seconds (in absolute time). These operations currently 
include many backup and recovery functions, statistics 
gathering, and query execution. More operations are added 
for every Oracle Database release. 


VSSESSIOtJ_WAIT 


Displays the current or last wait for each session 


VS SES SIOH_WAIT_HIS TORY 


Lists the last ten wait events for each active session 


VSWAIT_CHAINS 


Displays information about blocked sessions 


VS SYS STAT 


Contains session statistics 


VS RES OURCE_LrMI T 


Provides information about current and maximum global 
resource utilization for some system resources 


VSSQLAREA 


Contains statistics about shared SQL areas. Contains one row 
for each SQL string. Provides statistics about SQL statements 
that are in memory, parsed, and ready for execution 
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Managing Memory 



In this chapter; 

■ About Memorv Management 

■ Memory Architecture Overview 

■ Using Automatic Mem.ory Management 

■ Configuring Memory Manually 

■ Memory Management Reference 



About Memory Management 



Memor\' management involves maintaining optimal sizes for the Oracle Database 
instance niemor}" structures as demands on the database change. The memorv 
structures that must be managed are the svstem global area (SGA) and the instance 
program global area (instance PGA), 

Oracle Database supports various memorv management methods, which are chosen 
by initialization parameter settings. Oracle recommends that vou enable the method 
known as auiomalic memory iiianagciin'iit. 

Automatic Memory Management 

Beginning with Release llg, Oracle Database can manage the SGA memory and 
instance PGA memory completelv autoniaticallv. You designate onlv the total memory 
size to be used bv the instance, and Oracle Database dvnamicallv exchanges memory 
between the SGA and the instance PGA as needed to meet processing demands. This 
capabilit\' is referred to as iiiitoiiiiilic lucmonj luanagciuciif. With this memory 
management method, the database also dynamicallv tunes the sizes of the individual 
SGA components and the sizes of the individual PGAs. 

Manual Memory Management 

If vou prefer to exercise more direct control o\'er the sizes of individual memory 
components, you can disable automatic memorv management and configure the 
database for manual niemor\" management. There are a few different methods 
available for manual memory management. Some of these methods retain some 
degree of automation. The methods therefore var\' in the amount of effort and 
knowledge required by the DBA. These methods are: 

■ Automatic shared memory management - for the SGA 

■ Manual shared memory management - for the SGA 

■ Automatic PGA memorv management - for the instance PGA 
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■ Manual PGA memory m.aiiagement - for the instance PGA 

These memorv management methods are described later in tliis cliapter. 

Note: The easiest way to manage memorv is to use the graphical 
user interface of Oracle Enterprise Manager 

To manage memory with Enterprise Manager; 

1. Do one of the following: 

- If you are using Oracle Enterprise Manager Database Control, access the 
Database Home page. See Ornch Database 2 Day DBA for instructions. 

- If you are using Oracle Enterprise Manager Grid Control, go to the 
desired database target. The Database Home page is displayed. 

2. At the top of the page, click Server to display the Server page. 

3. In the Database Configuration section, click Memory Advisors. 

See Also: Oracle DaSabiKC Concepts for an introduction to the various 
automatic and manual methods of managing memory. 

Memory Architecture Overview 

The basic memory structures associated with Oracle Database include: 

. System Global Area (SGA) 

The SGA is a group of shared memor\' structures, known as SGA components, that 
contain data and control information for one Oracle Database instance. The SGA is 
shared by all server and background processes. Examples of data stored in the 
SGA include cached data blocks and shared SQL areas. 

. Program Global Area (PGA) 

A PGA is a memorv region ttiat contains data and control information for a server 
process. It is nonshared memor;' created by Oracle Database when a server 
process is started. Access to the PGA is exclusive to the server process. There is 
one PGA for each server process. Background processes also allocate their own 
PGAs. The total PGA memor\' allocated for all background and server processes 
attached to an Oracle Database instance is referred to as the total instance PGA 
memory, and the collection of all individual PGAs is referred to as the total 
instance PGA, or just instance PGA, 

Figure 5-1 illustrates the relationships among these memorj' structures. 
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Figure 5-1 Oracle Database Memory Structures 
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See Also: Oracle DnhibiKt- Concepts for more information on memory 
architecture in an Oracle Database instance. 

Using Automatic Memory Management 

This section provides background information on the automatic memory management 
feature of Oracle Database, and includes instructions for enabling this feature. The 
following topics are covered: 

■ About Automatic Memory Management 

■ Enabling Automatic Memory Management 

■ Monitoring and Tuning Automatic Memory Management 

About Automatic Memory Management 

The simplest way to manage instance men\ory is to allow the Oracle Database instance 
to automatically manage and tune it for you. To do so (on most platforms), you set 
only a target memory size initialization parameter (MEM0RY_TARGET) and optionally a 
maximum memory' size initialization parameter (MEM0RY_MAX_TARGET). The instance 
then tunes to the target memory size, redistributing memory as needed between the 
system global area (SGA) and the instance program global area (instance PGA). 
Because the target memory initialization parameter is dynamic, you can change the 
target memor;' size at any time without restarting the database. The maximum 
memor\' size serves as an upper limit so that you cannot accidentally set the target 
memor;' size too high, and so that enough memon' is set aside for the Oracle Database 
instance in case you do want to increase total instance memor;' in the future. Because 
certain SGA components either cannot easily shrink or must remain at a minimum 
size, the instance also prevents you from setting the target memor\' size too low. 

If you create your database with Database Configuration Assistant (DBCA) and choose 
the basic installation option, automatic memory management is enabled. If I'ou choose 
advanced installation. Database Configuration Assistant (DBCA) enables you to select 
automatic memor}' management 
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Note: You cannot enable automatic memory management if the 
LOCK_SGA initialization parameter is TRUE, See Orada Database 
Reference for information about this parameter. 



See Also: 



"Platforms That Support Automatic Memory Management" on 
page 5-21 



Enabling Automatic Memory lUlanagement 



If vou did not enable automatic memory managen\ent upon database creation (either 
by selecting the proper options in DBCA or bv setting the appropriate initialization 
parameters for the CREATE DATABASE SQL statement), you can enable it at a later 
time. Enabling automatic memory management involves a shutdown and restart of 
the database. 

To enable automatic memory management 

1. Start SQL'Plus and connect to the database as SYSDBA, 

See "About Database Administrator Securit\' and Privileges" on page 1-13 and 
"Database Administrator Authentication" on page 1-14 for instructions, 

2. Calculate the minimum value for MEMORY_TARGET as follows: 

a. Determine the current sizes of SGA_TARGET and PGA_AGGREGATE_TARGET 
by entering the following SQL'Plus command: 

SHOW PARAMETER TARGET 

SQL'Plus displavs the values of all initialization parameters with the string 
TARGET in the parameter name, 

HME TYPE VALUE 

archive_lag_target integer 

db_fla3hback_ret exit ion_tar get integer 1440 

faat_start_io_target integer 

faat_start_mttr_target integer 

memorY_max_target big integer 

inemorY_target big integer 

pga_aggregate_target big integer 90H 

sga_target big integer 272M 

b. Run the following query to determine the maximum instance PGA allocated 
since the database was started: 

select value from vjpgastat where narae= ' maximum PGA allocated'; 

c. Compute the maximum value between the querv result from step 2b and 

PGA_AGGREGATE_TARGET, Add SGA_TARGET to this value, 

inemory_target = sga_target + max(pga_aggregate_target, maximum PGA 
allocated} 

For example, if SGA_TARGET is 272M and PGA_AGGREGATE_TARGET is 90M as 
shown above, and if the maximum PGA allocated is determined to be 120M, then 
MEMORY_TARGET should be at least 392M (272M -h 120M), 
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3. Choose the value for MEMORY_TARGET that you want to use. 

This can be the minimum value that vou computed in step 2, or vou can choose to 
use a larger value if you have enough phvsical memor\" available. 

4. For the MEMORY_MAX_TARGET initialization parameter, decide on a maximum 
amount of memon' that vou would want to allocate to the database for the 
foreseeable future. That is, determine the maximum value for the sum of the SGA 
and instance PGA sizes. This number can be larger than or the same as the 
MEMORY_TARGET value that you chose in the previous step. 

5. Do one of the following: 

■ If vou started vour Oracle Database instance with a server parameter file, 
which is the default if you created the database with the Database 
Configuration Assistant (DBCA), enter the following command: 

ALTER SYSTEM SET MEMORY_MAX_TARGET = iM SCOPE = SPFII£; 

where ii is the value that vou computed in Step 4. 

The SCOPE = SPFILE clause sets the value only in the server parameter file, 
and not for the running instance. You must include this SCOPE clause because 
MEMORY_MAX_TARGET is not a dynamic initialization parameter. 

■ If vou started your instance with a text initialization parameter file, manually 
edit the file so that it contains the foUowing statements: 

memory_inax_target = dM 
memory_target = nM 

where n is the value that vou determined in Step 4, and iii is the value that you 
determined in step 3, 

Note: In a text initialization parameter file, if you omit the line for 

MEMO RY_MAX_TAR GET and include a value for MEMO RY_TAR GET, the 
database automatically sets MEMORY_MAX_TARGET to the value of 
MEMO RY_TAR GET. If you omit the line for MEMORY_TARGET and 
include a value for MEMORY_MAX_TARGET, the MEMORY_TARGET 
parameter defaults to zero. After startup, you can then dynamically 
change MEMORY_TARGET to a nonzero value, provided that it does not 
exceed the value of MEMORY MAX TARGET. 



6. Shut down and restart the database. 

See Chapter 3, "Starting Up and Shutting Down" on page 3-1 for instructions. 

7. If you started your Oracle Database instance with a server parameter file, enter the 
following commands: 

ALTER SYSTEM SET MEMORY_TfiRGET = r*!; 

ALTER SYSTEM SET SGA_TARGET = 0; 

ALTER SYSTEM SET PGA_AGGREGATE_TARGET = 0; 



w^heie n is the value that you determined in step 3. 
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Note: The preceding steps instruct you to set SGA_TARGET and 
PGA_AGGREGATE_TARGET to zero SO that the sizes of the SG A and 
instance PGA are tuned up and down as required, without 
restrictions. You can omit the statements that set these parameter 
values to zero and leave either or both of the values as positive 
numbers. In this case, the values act as minimum values for the sizes 
of the SGA or instance PGA. 



See Also: 

■ "About Automatic Memory Management" on page 5-3 

■ "Memory Architecture 0\'er\'iew" on page 5-2 

■ Oracle Database SQL Language Reference for information on the 

ALTER SYSTEM SQL statement 

Monitoring and Tuning Automatic IVIemoty Management 

The dynamic performance view VSMEM0RY_DYHAMIC_COMPONENTS shows the 
current sizes of all dvnamicallv tuned memorv components, including the total sizes 
of the SGA and instance PGA. 

The view VSMEMORY_TARGET_ADVICE provides tuning advice for the MEMO RY_ 
TARGET initialization parameter, 

SQL> select * from v$iiiemory_target_ad\'ice order by iiiemory_Eize; 

MEM0RY_3IZE MEHORY_SIZE_FACT0R E3TD_DB_TIME ESTD_DB_TIME_FACTOR VERSIOH 

ISO 
270 
360 
450 
540 
630 
720 

The row with the MEMORY_SI ZE_FACTOR of 1 shows the current size of memorv, as 
set by the MEMORY_TAE.GET initialization parameter, and the amount of DB time 
required to complete the current workload. In previous and subsequent rows, the 
results show a number of alternative MEMORY_TARGET sizes. For each alternative size, 
the database shows the size factor (the multiple of the current size), and the estimated 
DB time to complete the current workload if the MEMORY_TARGET parameter were 
changed to the alternative size. Notice that for a total memorv size smaller than the 
current MEMORY_TARGET size, estimated DB time increases. Notice also that in this 
example, there is nothing to be gained bv increasing total memory size bevond 450MB, 
However, this situation might change if a complete workload has not yet been run. 

Enterprise Manager provides an easy-to-use graphical memory advisor to help you 
select an optimal size for MEMORY_TARGET, See Orack Database 2 Day DBA for details. 

See Also: 

■ Oracle Database Reference for more information about these 
dynamic performance view^s 

■ Oracle Database Performance Tuning Guide for a definition of DB 
time. 
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If voii prefer fo exercise more direct control over flie sizes of individual memory 
components, you can disable automatic memory management and configure the 
database for manual memory management. There are two different manual memory 
management methods for the SGA, and tivo for the instance PGA, 

The two manual memor\' management methods for the SGA vary in the amount of 
effort and knowledge required by the DBA. With automatic shared mevwry management, 
you set target and maximum sizes for the SGA. The database then tunes the total size 
of the SGA to your designated target, and dvnamicallv tunes the sizes of many SGA 
components. With iiiniiiiiil iharcd memory management, you set the sizes of several 
individual SGA components, thereby determining the overall SGA size. You then 
manually tune these individual SGA components on an ongoing basis. 

For the instance PGA, there is aiifomafic PGA memonj mimagcment, in which vou set a 
target size for the instance PGA. The database then tunes the size of the instance PGA 
to vour target, and dynamicallv tunes the sizes of individual PGAs, There is also 
manual PGA memory management, in which you set maximum work area size for each 
type of SQL operator (such as sort or hash-join). This memory management method, 
although supported, is not recommended. 

The following sections provide details on all of these manual memor}' management 
methods: 

■ Using Automatic Shared Memory Management 

■ Using Manual Shared Memon' Management 

■ Using Automatic PGA Memorv Management 

■ Using Manual PGA Memorv Management 

See Also: Oracle Database Concepts for an overview of Oracle 
Database memory management methods. 

Using Automatic Shared ll/lemory Management 

This section contains the following topics: 

About Automatic Shared Memory Management 

Components and Granules in the SGA 

Setting Maxinaum SGA Size 

Setting SGA Target Size 

Enabling Automatic Shared Memory Management 

Automatic Shared Memorv Management Advanced Topics 

See Also: 

■ Orach Database Performance Tuning Guide for information about 
tuning the components of the SGA 

About Automatic Shared Memory Management 

Automatic Shared Memorv Management simplifies SGA memorv management. You 
specifv the total amount of SGA memorv available to an instance using the SGA_ 
TARGET initialization parameter and Oracle Database automaticallv distributes this 
memor}' among the various SGA components to ensure the most effective memory 
utilization. 
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When automatic shared memorv management is enabled, the sizes of the different 
SGA components are flexible and can adapt to the needs of a workload without 
requiring any additional configuration. The database automatically distributes the 
available memor}' among the various components as required, allowing the system to 
maximize the use of all available SGA memor}'. 

Oracle Database remembers the sizes of the automaticallv tuned components across 
instance shutdowns if you are using a server parameter file (SPFILE). As a result, the 
svstem does need to learn the characteristics of the workload again each time an 
instance is started. It can begin with information from the past instance and continue 
evaluating workload where it left off at the last shutdown. 

Components and Granules in the SGA 

The SGA comprises a number of memory components, which are pools of memory 
used to satisfy a particular class of memory allocation requests. Examples of memory 
components include the shared pool (used to allocate memory for SQL and PL /SQL 
execution), the Java pool (used for Java objects and other Java execution memory), and 
the buffer cache (used for caching disk blocks). All SGA components allocate and 
deallocate space in units of granules. Oracle Database tracks SGA memorv use in 
internal numbers of granules for each SGA component. 

The memory for dynamic components in the SGA is allocated in the unit of granules. 
Granule size is determined by total SGA size. Generally speaking, on most platforms, 
if the total SGA size is equal to or less than 1 GB, then granule size is 4 MB, For SGAs 
larger than 1 GB, granule size is 16 MB. Some platform dependencies may arise. For 
example, on 32-bit Windows NT, the granule size is 8 MB for SGAs larger than 1 GB. 
Consult your operating system specific documentation for more details. 

You can query the V$SGAINFO view to see the granule size that is being used by an 
instance. The same granule size is used for all components in the SGA. 

If vou specify a size for a component that is not a multiple of granule size, Oracle 
Database rounds the specified size up to the nearest multiple. For example, if the 
granule size is 4 MB and you specify DB_CACHE_S I ZE as 10 MB, the database actually 
allocates 12 MB. 

Setting Maximum SGA Size 

The SGA_MAX_SI ZE initialization parameter specifies the maximum size of the System 
Global Area for the lifetime of the instance. You can dynamically alter the initialization 
parameters affecting the size of the buffer caches, shared pool, large pool, Java pool, 
and streams pool but only to the extent that the sum of these sizes and the sizes of the 
other components of the SGA (fixed SGA, variable SGA, and redo log buffers) does 
not exceed the value specified by SGA_MAX_SI ZE. 

If you do not specify SGA_MAX_SIZE, then Oracle Database selects a default value that 
is the sum of all components specified or defaulted at initialization time. If vou do 
specify SGA_MAX_SIZE, and at the time the database is initialized the value is less 
than the sum of the memory allocated for all components, either explicitly in the 
parameter file or by default, then the database ignores the setting for SGA_MAX_SIZE 
and chooses a correct value for this parameter. 

Setting SGA Target Size 

You enable the automatic shared memory management feature by setting the SGA_ 
TARGET parameter to a nonzero value. This parameter in effect replaces the 
parameters that control the memory allocated for a specific set of individual 
components, which are now automatically and dynamically resized (tuned) as needed. 



5-8 Oracle Database Administrator's Guide 



Configuring Memory Manually 



Note: The STaTISTICS_LEVEL initialization parameter must be set 
to TYPICAL (the defauh) or ALL for niitom.atic shared memory 
m.anagem.ent to function. 



The SGA_TARGKT initialization parameter reflects the total size of the SGA. Table 5-1 
lists the SGA components for which SGA_TARGET includes memory' — the 
automatically sized SGA components — and the initialization parameters 
corresponding to those components. 

Table 5-1 Automatically Sized SGA Components and Corresponding Parameters 



SGA Component 


Initialization Parameter 


Filled SGA uind other internal allocations needed by the Oracle 
Database instance 


N/A 


The shared pool 


SHAKED_POOL_S I ZE 


The large pool 


LARGE_POOL_SIZE 


The Java pool 


JAVA_PO0L_SIZE 


The buffer cache 


DB_CACHE_SIZE 


The Streams pool 


STREAMS_POOL_SIZE 



The parameters listed in Table 5-2, if they are set, take their memory from SGA_ 
TARGET, leaving what is available for the components listed in Table 5-1. 

Table 5-2 Manually Sized SGA Components that Use SGAJTARGET Space 



SGA Component 


Initialization Parameter 


The log buffer 


LOG_BUFFER 


The keep and recycle buffer caches 


DB_KEEP_CACHE_S I ZE 
DB_RECYCLE_CACHE_S I ZE 


Nonstandard block size buffer caches 


DB_nK_CACHE_S I ZE 



In addition to setting SGA_TARGET to a nonzero value, you must set the value of all 
automaticallv sized SGA components to zero to enable full automatic tuning of these 
components. 

Alternatively, you can set one or more of the automatically sized SGA components to a 
nonzero value, which is then used as the minimum setting for that component during 
SGA tuning. This is discussed in detail later in this section. 



Note: An easier way to enable automatic shared memory 
management is to use Oracle Enterprise Manager (EM). When you 
enable automatic shared memorv management and set the Total SGA 
Size, EM automatically generates the ALTER SYSTEM statements to 
set SGA_TARGET to the specified size and to set all automaticallv sized 
SGA components to zero. 

If you use SQL'Plus to set SGA_TARGET, you must then set the 
automatically sized SGA components to zero or to a minimum value. 
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SGA and Virtual Memory For optimal performance in most systems, tlie entire SGA 
sliould fit in real memory. If it does not, and if virtual memorv is used to store parts of 
it, then overall database svstem performance can decrease dramatically. The reason for 
this is that portions of the SGA are paged (written to and read from disk) bv the 
operating sj'stem. 

See your operating system documentation for instructions for monitoring paging 
activity. You can also view paging activit\' from the Performance propert\' page of the 
Host page of Enterprise Manager. 

Monitoring and Tuning SGA Target Size The VS SGAINFO view provides information on the 
current tuned sizes of various SGA components. 

The VSSGA_TARGET_ADVICE view provides information that helps you decide on a 
value for SGA_TARGET. 

SQL> select * from v3sga_target_advice order by sga_size; 

SGA SIZE SGA SIZE FACTOR ESTD DB TIME ESTD DB TIME FACTOR ESTD PHYSICAL READS 



290 


.5 


448176 


435 


.75 


339336 


BSD 


1 


270344 


725 


1.25 


239038 


87 □ 


1.5 


211517 


1015 


1.75 


201866 


1160 


2 


200703 



1.5578 


1536103 


1.2552 


1536103 


1 


1201780 


.8842 


907584 


.7824 


513881 


.7467 


513881 


.7424 


513881 



The Lnformation in this view is similar to that provided in the V$MEMORY_TARGET_ 
ADVICE view for automatic memory miinagement. See "Monitoring and Tuning 
Automatic Memory Management" on page 5-6 for an explanation of that view. 

Enterprise Manager provides an easy-to-use graphical memory advisor to help you 
select an optimal size for SGA_TARGET, See Oracle Database 2 Day DBA for details. 

See Also: Oracle Database Reference for more information about these 
d\'namic performance view^s 

Enabling Automatic Shared Memory l\ianagement 

The procedure for enabling automatic shared memor\" management (ASMM) differs 
depending on whether vou are changing to ASMM from manual shared memory 
management or from automatic memory management. 

To change lo ASMM from manual shared memory management: 

1. Run the following query to obtain a value for SGA_TARGET: 

SELECT ( 

(SELECT SUM[value} FROM V3SGA) - 

(SELECT CURRENT_SIZE FROM VSSGA_DYNMIC_FREE_MEMORY) 

) "SGA_TMGET" 
FROM DUAL; 

2. Set the value of SGA_TARGET, either by editing the text initialization parameter 
file and restarting the database, or by issuing the following statement: 

ALTER SYSTEM SET SGA_TARGET=i.'aIue [SCOPE= [SPFILE |HEMORY|BOTH1 ] 

where value is the value computed in step 1 or is some value between the sum of 
all SGA component sizes and SGA_MAX_SI ZE. For more information on the 
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ALTER SYSTEM statement and its SCOPE clause, see Orach- Diilahnst' SQL Language 
Reference. 

3. Do one of the following: 

■ For more complete automatic tuning, set the values of tlie automatically sized 
SGA components listed in Table 5-1 to zero. Do this bv editing the text 
initiiilization parameter file or by issuing ALTER SYSTEM statements, 

■ To control the minimum size of one or more automatically sized SGA 
components, set those component sizes to the desired value, (See the next 
section for details.) Set the values of the other automatically sized SGA 
components to zero. Do this bv editing the text initialization param.eter file or 
by issuing ALTER SYSTEM statements. 



To change to ASMM from automatic memory management; 

1. Set the MEMORY_TARGET initialization parameter to 0. 

ALTER SYSTEM SET MEMORY_TARGET = 0; 

The database sets SGA_TARGET based on current SGA memory allocation. 

2. Do one of the following: 

■ For more complete automatic tuning, set the values of the automaticallv sized 
SGA components listed in Table 5-1 to zero. Do this by editing the text 
initialization parameter file or by issuing ALTER SYSTEM statements. 

■ To control the minimum size of one or more automaticallv sized SGA 
components, set those component sizes to the desired value, (See the next 
section for details.) Set the values of the other automaticallv sized SGA 
components to zero. Do this bv editing the text initialization parameter file or 
by issuing ALTER SYSTEM statements. 

Example For example, suppose you currentlv have the following configuration of 
parameters for an instance configured for manual shared memor}' management and 
with SGA_MAX_SIZE set to 1200M: 

■ SHARED_POOL_SI ZE = ZOOM 

■ DB_CACHE_SI ZE = 500M 

■ LARGE_POOL_SI ZE=200M 

Also assume the following querv results: 

Query Result 

SELECT SUM(value} FROM V^SGA 1200M 

SELECT CORHENT_SIZE FROM VSSGA_DYHAMIC_FREE_MEMORY 208M 

You can take advantage of automatic shared memorv management bv setting Total 
SGA Size to 992M in Oracle Enterprise Manager, or bv issuing the following 
statements: 

ALTER SYSTEM SET SGA_TRRGET = 992H; 
ALTER SYSTEM SET SHaKED_P0OL_SIZE = 0; 
ALTER SYSTEM SET LARGE_P00L_3IZE = 0; 
ALTER SYSTEM SET JAVA_POOL_SIZE = 0; 
ALTER SYSTEM SET DB_CACHE_SIZE = 0; 
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ALTER SYSTEM SET STHEMS_PO0L_SIZE = 0; 

where 992M = 1200M minus 208M. 

Automatic Shared Memory Management Advanced Topics 

This section provides a closer look at automatic shared memory management. It 
includes the following topics: 

Setting Minimums for Automatically Sized SGA Components 

Automatic Tuning and the Shared Pool 

Dvnamic Modification of SGA_TARGET 

Modifying Parameters for Automatically Sized Components 

Modifying Parameters for Manually Sized Components 

Setting Minimums for Automatically Sized SGA Components You can exercise some control 
over the size of the automaticallv sized SGA components bv specifying minimum 
values for the parameters corresponding to these components. Doing so can be useful 
if vou know that an application cannot function properlv without a minimum amount 
of memorv in specific components. You specify the minimum amount of SGA space 
for a component by setting a value for its corresponding initialization parameter 

Manually limiting the minimum size of one or more automaticallv sized components 
reduces the total amount of memory available for dynamic adjustment. This reduction 
in turn limits the abiliK" of the svstem to adapt to workload changes. Therefore, this 
practice is not recommended except in exceptional cases. The default automatic 
management behavior maximizes both system performance and the use of available 
resources. 

Automatic Tuning and the Shared Pool When the automatic shared memory management 
feature is enabled, the internal tuning algorithm tries to determine an optimal size for 
the shared pool based on the workload. It usuallv converges on this value bv 
increasing in small increments over time. However, the internal tuning algorithm 
tvpically does not attempt to shrink the shared pool, because the presence of open 
cursors, pirmed PL/SQL packages, and other SQL execution state in the shared pool 
make it impossible to find granules that can be freed. Therefore, the tuning algorithm 
onlv tries to increase the shared pool in conservative increments, starting from a 
conservative size and stabilizing the shared pool at a size that produces the optimal 
performance benefit. 

Dynamic Modification of SGA_TARGET The SGA_TARGET parameter can be dynamically 
increased up to the value specified for the SGA_MAX_SIZE parameter, and it can also 
be reduced. If you reduce the value of SGA_TARGET, the system identifies one or more 
automaticallv tuned components for which to release memor}'. You can reduce SGA_ 
TARGET until one or more automaticallv tuned components reach their minimum size. 
Oracle Database determines the minimum allowable value for SGA_TARGET taking 
into account several factors, including values set for the automaticaUy sized 
components, manuaLy sized components that use SGA_TARGET space, and number of 
CPUs. 

The change in the amount of physical memorv consumed when SGA_TARGET is 
modified depends on the operating system. On some UNIX platforms that do not 
support dvnamic shared memorv, the phvsical memorv in use by the SGA is equal to 
the value of the SGA_MAX_SIZE parameter On such platforms, there is no real benefit 
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insetting SGA_TARGET to a value smaller than SGA_MAX_SIZE. Therefore, setting 
SGA_MAX_SI ZE on those platforms is not recommended. 

On other platforms, such as Solaris and Windows, the physical memory consumed by 
the SGA is equal to the value of SGA.TARGET, 

For example, suppose you have an environment with the following configuration: 

■ SGA_MAX_SIZE = 1024M 

■ SGA_TARGET = 512M 

■ DB_8K_CACHE_SI ZE = 128M 

In this example, the value of SGA_TARGET can be resized up to 1024M and can also be 
reduced until one or more of the automatically sized components reaches its minimum 
size. The exact value depends on environmental factors such as the number of CPUs 
on the system. However, the value of DB_8K_CACHE_SIZE remains fixed at all times 
at 128m' 

Note: When enabling automatic shared memory management, it is 
best to set SGA_TARGET to the desired nonzero value before starting 
the database. Dynamically modifying SGA_TARGET from zero to a 
nonzero value mav not achieve the desired results because the shared 
pool mav not be able to shrink. After startup, you can dynamically 
tune SGA_TARGET up or down as required. 

Modifying Parameters for Automatically Sized Components When sga_target is not set, 
the automatic shared memorv management feature is not enabled. Therefore the rules 
governing resize for all component parameters are the same as in earlier releases. 
However, when automatic shared memor}' management is enabled, the manuallv 
specified sizes of automatically sized components serve as a lower bound for the size 
of the components. You can modify this limit dynamically by changing the values of 
the corresponding parameters. 

If the specified lower limit for the size of a given SGA component is less than its 
current size, there is no immediate change in the size of that component. The new 
setting only limits the automatic tuning algorithm to that reduced minimum size in 
the future. For example, consider the following configuration: 

■ SGA_TARGET = 512M 

■ LARGE_POOL_SI ZE = 256M 

■ Current actual large pool size = 284M 

In this example, if vou increase the value of LARGE_POOL_SIZE to a value greater 
than the actual current size of the component, the system expands the component to 
accommodate the increased minimum size. For example, if you increase the value of 
LARGE_POOL_SI ZE to 300M, then the system increases the large pool incrementally 
until it reaches 300M. This resizing occurs at the expense of one or more automatically 
tuned components. 

If you decrease the value of LARGE_POOL_SIZE to 200, there is no immediate change 
in the size of that component. The new setting only limits the reduction of the large 
pool size to 200 M in the future. 

Modifying Parameters for Manually Sized Components Parameters for manually sized 
components can be dynamicallv altered as well. However, rather than setting a 
minimum size, the value of the parameter specifies the precise size of the 
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correspondmg component. When, vou increase the size of a manually sized 
component, extra memory is taken away from one or more automatically sized 
components. When you decrease the size of a manually sized component, the m.emory 
that is released is given to the automatically sized components. 

For example, consider this configuration; 

■ 3GA_TARGET = 512M 

■ DB_8K_CACHE_SIZE = 128M 

In this example, increasing DB_8K_c;ache_SIZE by 16 M to 144M means that the 16M 
is taken awav from the automatically sized components. Likewise, reducing DB_8K_ 
CACHE_SI ZE by 16M to 112M means that the 16M is given to the automatically sized 
com.ponents. 

Using Manual Shared Memory Management 

If you decide not to use automatic memory management or automatic shared memory 
management, you must manually configure several SGA component sizes, and then 
monitor and tune these sizes on an ongoing basis as the database workload changes. 
This section provides guidelines on setting the parameters that control the sizes of 
these SGA components. 

If you create your database with DBCA and choose manual shared memory 
management, DBCA provides fields where vou must enter sizes for the buffer cache, 
shared pool, large pool, and Java pool. It then sets the corresponding initialization 
parameters in the server parameter file (SPFILE) that it creates. If you instead create 
the database with the CREATE DATABASE SQL statement and a text initialization 
parameter file, you can do one of the following; 

■ Provide values for the initialization parameters that set SGA component sizes. 

■ OmitSGA component size parameters from the text initialization file. Oracle 
Database chooses reasonable defaults for any component whose size you do not 
set. 

This section contains the following topics; 

Enabling Manual Shared Memory Management 

Setting the Buffer Cache Initialization Parameters 

Specifying the Shared Pool Size 

Specifying the Large Pool Size 

Specifying the Java Pool Size 

Specifying the Streams Pool Size 

Specifying the Result Cache Maximum Size 

Specifying Miscellaneous SGA Initialization Parameters 

Enabling Manual Shared Memory Management 

There is no initialization parameter that in itself enables manual shared memory 
management You effectively enable manual shared memorv management bv 
disabling both automatic memory management and automatic shared memorv 
management 

To enable manual shared memory management; 

1. Set the MEMORY_TARGET initialization parameter to 0. 
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2. Set the SGA_TARGET initialization parameter to 0. 

You must then set vahies for the various SGA components, as described in the 
followingsections. 

Setting the Buffer Cache Initialization Parameters 

The buffer cache initialization parameters determine the size of the buffer cache 
component of the SGA. You use them to specify the sizes of caches for the various 
block sizes used by the database. These initialization parameters are all dynamic. 

The size of a buffer cache affects performance. Larger cache sizes generally reduce the 
number of disk reads and writes. However, a large cache m.ay take up too much 
memor\' and induce memor\' paging or swapping. 

Oracle Database supports multiple block sizes in a database. If you create tablespaces 
with non-standard block sizes, vou must configure non-standard block size buffers to 
accommodate these tablespaces. The standard block size is used for the SYSTEM 
tablespace. You specify the standard block size by setting the initialization parameter 
DB_BL0CK_3IZE. Legitimate values are from 2K to 32K, 

If you intend to use multiple block sizes in your database, vou must have the DB_ 
CACHE_SIZE and at least one DB_nK_CACHE_SIZE parameter set. Oracle Database 
assigns an appropriate default value to the DB_CACHE_SIZE parameter, but the DB_ 
nK_CACHE_SI ZE parameters default to 0, and no additional block size caches are 
configured. 

The sizes and numbers of non-standard block size buffers are specified by the 
following parameters: 

DB_2K_CACHE_SIZE 
DB_4K_CACHE_SIZE 
DB_8K_CACHE_SIZE 
EB_16K_CACHE_S IZE 
DB_3 2K_CACHE_S IZE 

Each parameter specifies the size of the cache for the corresponding block size. 

Note: Platform-specific restrictions regarding the maximum block 
size apply, so some of these sizes might not be allowed on some 
platforms. 



See Also: 'Specifying Nonstandard Block Sizes for Tablespaces" on 
page 12-14 

Example ol Setting Block and Cache Sizes 

EB_BLOCK_S IZE=4 09 5 

I3B_CACHE_S IZE= 10 2 4M 
DB_2K_CACHE_SIZE=2 56M 
DB_8K_CACHE_SI ZE= 5 1 2M 

In the preceding example, the parameter DB_BLOCK_SIZE sets the standard block size 
of the database to 4K. The size of the caclie of standard block size buffers is 1024MB, 
Additionally, 2K and 8K caches are also configured, with sizes of 2E'6MB and 512MB, 
respectively. 
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Note: The DB_nK_CACHE_SI ZE parameters cannot be used to size 
the cache for the standard block size. If the value of DB_BLOCK_SIZB 
is wK, it is invalid to set DB_iiK_CACHE_SI ZE. The size of the cache 
for the standard block size is always determined from the value of 

DB CACHE SIZE. 



The cache has a limited size, so not all the data on disk can fit in the cache. When the 
cache is full, subsequent cache misses cause Oracle Database to write dirt}' data 
already in the cache to disk to make room for the new data. (If a buffer is not dirtv, it 
does not need to be written to disk before a new block can be read into the buffer.) 
Subsequent access to any data that was written to disk and then overwritten results in 
additional cache misses. 

The size of the cache affects the likelihood that a request for data results in a cache hit. 
If the cache is large, it is more likely to contain the data that is requested. Increasing 
the size of a cache increases the percentage of data requests that result in cache hits. 

You can change the size of the buffer cache while the instance is running, without 
having to shut down the database. Do this with the ALTER SYSTEM statement. 

Use the fixed view VSBUFFER_POOL to track the sizes of the different cache 
com.ponents and any pending resize opierations. 

Multiple Buffer Pools You can configure the database buffer cache with separate buffer 
pools that either keep data in the buffer cache or make the buffers available for new 
data immediately after using the data blocks. Particular schema objects (tables, 
clusters, indexes, and partitions) can then be assigned to the appropriate buffer pool to 
control the wav their data blocks age out of the cache, 

■ The KEEP buffer pool retains the schema object's data blocks in memory, 

■ The RECYCLE buffer pool eliminates data blocks from memory as soon as they are 
no longer needed, 

■ The DEFAULT buffer pool contains data blocks from schema objects that are not 
assigned to anv buffer pool, as well as schema objects that are explicitly assigned 

to the DEFAULT pool. 

The initialization parameters that configure the KEEP and RECYCLE buffer pools are 

DB KEEP CACHE SIZEandCB RECYCLE CACHE SIZE. 



Note: Multiple buffer pools are only available for the standard block 
size. Non-standard block size caches have a single DEFAULT pool. 



See Also: 

■ Oracle Database Performance Timing Guide for information about 
tuning the buffer cache and for more information about multiple 
buffer pools 

Specifying tlie Sliared Pooi Size 

The SHARED_POOL_SIZE initialization parameter is a dynamic parameter that lets 
you specify or adjust the size of the shared pool component of the SGA, Oracle 
Database selects an appropriate default value. 
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In releases before Oracle Database 10;:; Release 1. the amount of shared pool memory 
that was allocated was equal to the value of the SHARED_POOL_SIZE initialization 
parameter plus the amount of internal SGA overhead computed during instance 
startup. The internal SGA overhead refers to memorv that is allocated bv Oracle 
Database during startup, based on the values of several other initialization parameters. 
This memory is used to maintain state for different server components in the SGA. For 
example, if the SHARED_POOL_SI ZE parameter is set to 64MB and the internal SGA 
overhead is computed to be 12MB, the real size of the shared pool is 64+12=76MB, 
although the value of the SHARED_P00L_3IZE parameter is still displayed as 64MB. 

Starting with Oracle Database lOg Release 1, the size of the interna! SGA overhead is 
included in the user-specified value of SHARED_POOL_SI ZE. If vou are not using 
automatic memorv management or automatic shared memory management, the 
amount of shared pool memory that is allocated at startup is equal to the value of the 
SHARED_POOL_SI ZE initialization parameter, rounded up to a multiple of the granule 
size. You must therefore set this parameter so that it includes the internal SGA 
overhead in addition to the desired value for shared pool size. In the previous 
example, if the SHARED_POOL_SI ZE parameter is set to 64MB at startup, then the 
available shared pool after startup is 64-12=E'2MB, assuming the value of internal SGA 
overhead remains unchanged. In order to maintain an effective value of 64MB for 
shared pool memory after startup, you must set the SHARED_POOL_SI ZE parameter 
to 64+12=76MB, 

When migrating from a release that is earlier than Oracle Database Wg Release 1. the 
Oracle Database ll;f migration utilities recommend a new value for this parameter 
based on the value of internal SGA overhead in the pre-upgrade environment and 
based on the old value of this parameter. Beginning with Oracle Database 10^, the 
exact value of internal SGA overhead, also known as startup overhead in the shared 
pool, can be queried from the V5SGAIISIF0 view. Also, in manual shared memorv 
management mode, if the user-specified value of SHARED_POOL_SIZE is too small to 
accommodate even the requirements of internal SGA overhead, then Oracle Database 
generates an ORA-371 error during startup, with a suggested value to use for the 
SHARED_POOL_SIZE parameter 

When you use automatic shared memorv management in Oracle Database 11^, the 
shared pool is automatically tuned, and an ORA-371 error would not be generated. 

The Result Cache and Shared Pool Size The result cache takes its memory from the shared 
pool. Therefore, if vou expect to increase the maximum size of the result cache, take 
this into consideration when sizing the shared pool. 

See Also: "Specifving the Result Cache Maximum Size" on page 5-18 

Specifying tlie Large Pooi Size 

The LARGE_P00L_3IZE initialization parameter is a dynamic parameter that lets you 
specif\' or adjust the size of the large pool component of the SGA, The large pool is an 
optional component of the SGA. You must specif ically set the LARGE_POOL_SIZE 
parameter if vou want to create a large pool. Configuring the large pool is discussed in 
Orade Database Pcrfonnance Tuning Guide. 

Specifying tlie Java Pooi Size 

The JAVA_POOL_SIZE initialization parameter is a dvnamic parameter that lets vou 
specify or adjust the size of the Java pool component of the SGA. Oracle Database 
selects an appropriate default value. Configuration of the Java pool is discussed in 
Oracle Database Java Deueloper's Guide. 
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Specifying tlie Streams Pooi Size 

The STREAMS_POOL_SIZE initialization parameter is a dynamic parameter that lets 
you specify or adjust the size of the Streams Pool component of the SGA, If STREAMS_ 
POOL_SI ZE is set to 0, then the Oracle Streams product transfers memorv from the 
buffer cache to the Streams Pool when it is needed. For details, see the discussion of 
the Streams Pool in Oracle Streams Concepts and Adminislration. 

Specifying tlie Resuit Cache Maximum Size 

The RESULT_CACHE_MAX_giZE initialization parameter is a dynamic parameter that 
enables you to specify the maximum size of the result cache component of the SGA, 
Typically, there is no need to specify this parameter, because the default maximum 
size is chosen bv the database based on total memorv available to the SGA and on the 
memory management method currentiv in use. You can view the current default 
maximum size by displaying the value of the RESULT_CACHE_MAX_SIZE parameter 
If you want to change this maximum size, you can set RESULT_CACHE_MAX_SIZE 
with an ALTER SYSTEM statement or vou can specify this parameter in the text 
initialization parameter file. In each case, the value is rounded up to the nearest 
multiple of 32K. 

If RESULT_CACHE_MAX_SIZE is upon instance startup, the result cache is disabled. 
To reenable it you must set RESULT_CACHE_MAX_SIZE to a nonzero value (or remove 
this parameter from the text initialization parameter file to get the default maximum 
size) and then restart the database. 

Note that after starting the database with the result cache disabled, if you use an 
ALTER SYSTEM statement to set RESULT_CACHE_MAX_SIZE to a nonzero value but 
do not restart the database, querying the value of the RESULT_CACHE_MAX_SIZE 
parameter returns a nonzero value even though the result cache is still disabled. The 
value of RESULT_CACHE_MAX_SI ZE is therefore not the most reliable way to 
determine if the result cache is enabled. You can use the following query instead: 

SELECT iibmE_reEult_cache.Etatus{) ETiOM dual; 

DBMS_RESULT_CACHE . STATUS ( ) 

ENABLED 



The result cache takes its memory from the shared pool, so if you increase the 
maximum result cache size, consider also increasing the shared pool size. 

The view VSRESULT_CACHE_STATISTICS and the PL /SQL package procedure 
DBMS_RESULT_CACHE .MEMORY_REPORT display information to help you determine 
the amount of memory currently allocated to the result cache. 

The PL /SQL package function DBMS_RESULT_CACHE . FLUSH clears the result cache 
and releases all the memory back to the shared pool. 
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See Also: 

■ Orach' Dainbaw Performance Timing Guide for more information 
about the result cache 

■ Oracle Database PL/SQL Packages and T^pes Reference for more 
information about the DBMS_RESULT_CACHE package procedures 
and functions. 

■ Oracle Database Reference for more infoimation about the 

VSRESULT_CaCHE_STATISTICS view. 

■ Oracle Real Apj^lication Clusters Adm'mistration and Deployment 
Guide for information on setting RESULT_CACHE_MAX_3IZE for a 
cluster database. 

Specifying Misceilaneous SGA Initiaiization Parameters 

You can set a few additional initialization parameters to control how the SGA uses 
memory. 

Physical Memory The L0CK_SGA parameter, when set to TRUE, locks the entire SGA 
into physical memory. This parameter cannot be used in conjunction with automatic 
memon' management or automatic shared memory management. 

SGA Starting Address The shared_memory_address and hi_shared_memory_ 
ADDRESS parameters specify theSGA's starting address at runtime. These parameters 
are rarely used. For 64-bit platforms, HI_SHARED_MEMORY_ADDRESS specifies the 
high order 32 bits of the 64-bit address. 

Extended Buffer Cache Mechanism The use_iwdirect_data_buffers parameter 
enables the use of the extended buffer cache mechanism for 32-bit platforms that can 
support more than 4 GB of physical memory. On platforms that do not support this 
much physical memory, this parameter is ignored. This parameter cannot be used in 
conjunction with automatic niem.ory management or automatic shared memory 
management 

See Also: 

■ Oracle Database Reference for more information on these 
initiaiization parameters 

■ "Using Automatic Memory Management" on page 5-3 

■ "Using Automatic Shared Memory Management" on page 5-7 

Using Automatic PGA Memory Management 

By default, Oracle Database automatically and globally manages the total amount of 
memory dedicated to the instance PGA, You can control this amount by setting the 
initialization parameter PGA_AGGREGATE_TARGET, Oracle Database then tries to 
ensure that the total amount of PGA memory allocated across all database seryer 
processes and background processes never exceeds this target 

If vou create your database with DBCA, vou can specify a value for the total instance 
PGA, DBCA then sets the PGA_AGGREGATE_TARGET initialization parameters in the 
ser\er parameter file (SPFILE) that it creates. If you do not specify the total instance 
PGA, DBCA chooses a reasonable default 
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If you create the database with the CREATE DATABASE SQL statement and a text 
initiaUzation parameter file, you can provide a value for PGA_AGGREGATE_TARGET. If 
you omit this parameter, the database chooses a default value. 

With automatic PGA memorv management, sizing of SQL work areas for all dedicated 
server sessions is automatic and all '_AREA_SIZE initialization parameters are 
ignored for these sessions. At any given time, the total amount of PGA memory 
available to active work areas on the instance is automatically derived from the 
parameter PGA_AGGREGATE_TARGET. This amount is set to the value of PGA_ 
AGGREGATE_TARGET minus the PGA memory allocated for other purposes (for 
example, session memory). The resulting PGA memorv is then allotted to individual 
active work areas based on their specific memorv requirements. 

There are dynamic performance views that provide PGA memory use statistics. Most 
of these statistics are enabled when PGA_AGGREGATE_TARGET is set. 

■ Statistics on allocation and use of work area memor}' can be viewed in the 
following dynamic performance views: 

VSSYSSTAT 

VSSESSTAT 

VSPGASTAT 

V$SQL_WORKAREA 

VS SQL_WORKAREA_ACTIVE 

■ The following three columns in the VSPROCESS view report the PGA memorv 
allocated and used by an Oracle Database process; 

PGA_USED_MEM 
PGA_ALLOCATED_MEM 
PGA MAX MEM 



Note: The automatic PGA memory management method applies to 
work areas allocated by both dedicated and shared server process. See 
Orach Database Concepts for information about PGA memory 
allocation in dedicated and shared server modes. 



See Also: 

■ Orach Database Reference for information about views mentioned 
in this section 



Orach Database Performance Tuning Guide for information about 
using these views 



Using Manual PGA Memory Management 



Oracle Database supports manual PGA memory management, in which you manually 
tune SQL work areas. 

In releases earher than Oracle Database 10^, the database administrator controlled the 
maximum size of SQL work areas bv setting the following parameters: SORT_AREA_ 

SIZE, HASH_AREA_SIZE, BITMAP_MERGE_AREA_SIZE and CREATE_BITMAP_ 

AREA_SI ZE, Setting these parameters is difficult, because the maximum work area 
size is ideally selected from the data input size and the total number of work areas 
active in the system. These tivo factors vary greatly from one work area to another and 
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from one time to another. Thus, the various *_AREA_SI ZE parameters are difficult to 
tune under the best of circumstances. 

For this reason, Oracle strongly recommends that you leave automatic PGA memory 
management enabled. 

If vou decide to tune SQL work areas n\anuallv, vou must set the WORKAREA_SIZE_ 
POLICY initialization parameter to MANUAL. 

Note: The initialization parameter WORKAREA_S I ZE_POL ICY is a 
session- and svstem-level parameter that can take onlv two values: 
MANUAL or AUTO. The default is AUTO, You can set PGA_AGGREGATE_ 
TARGET, and then switch back and forth from auto to manual memory 
management mode. When W0RKAREA_SIZE_POLICY is set to AUTO, 
your settings for •_AREA_SIZE parameters are ignored. 



Memory Management Reference 



This section contains the following reference topics for memory management: 

■ Platforms That Support Automatic Memory Management 

■ Memory Management Data Dictionary Views 



Platforms That Support Automatic Memory Management 

The following platforms support automatic memory management — the Oracle 
Database abihty to automaticallv tune the sizes of the SGA and PGA, redistributing 
memory from one to the other on demand to optimize performance: 

Linux 

Solaris 

Windows 

HP-UX 

AIX 



Memory Management Data Dictionary Views 

The following dynamic performance views provide iiiform.ation on memory 
management: 



View Description 


VSSGA 


Displays summary information i\boutthe system 
globarareii(SGA)" 


V$SGAIHFO 


Displays size information about the SGA, including 
the sizes of different SGA components, the granule 
size, and free m.emory 


VSSGASTAT 


Displays detailed information about how memory is 
allocated within the shared pool, large pool, lava 
pool, and Streams pool. 
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View 


Description 


VS PGASTAT 


Displays PGA memorv usiige statistics as well ss 
statistics about the automatic PGA memory manager 
when it is enabled (that is, when PGA_AGGREGATE_ 
TARGET is set). Gumulative values in VS PGASTAT are 
accumulated since instance startup. 


VSHEMORY_DYHAMI C_COMPONEHTS 


Displays information on the current size of all 
automatically tuned and static memory components, 
with the last operation (for example, grow or shrink) 
that occurred on each. 


VS SGA_DYHAMIC_COMPOHEtTTS 


Displays the current sizes of all SGA components, and 
the last operation for each component. 


VS SGA_DYnaMIC_FEEE_MEMORY 


Displays information about the amount of SGA 
memorv available for future dynamic SGA resize 
operations. 


VSMEMORY_CURREHT_RES I Z E_OPS 


Displays information about resize operations that are 
currently in progress. A resize operation is an 
enlargement or reduction of the SGA, the instance 
PGA, or a dynamic SGA component. 


VS SGA_CUERENT_RES I ZE_OPS 


Displays information about dynamic SGA component 
resize operations that are currently in progress. 


VSMEMORY_RES I ZE_OPS 


Displays information about the last 800 completed 
memorv component resize operations, including 
automatic grow and shrink operations for SGA_ 
TARGET and PGA_AGGREGATE_TARGET. 


VSSGA_REg I ZE_OPS 


Displays information about the last 800 completed 

SGA component resize operations. 


VSMEMORY_TARGET_ADVICE 


Displays information that helps vou tune MEMORY_ 
TARGET if you enabled automatic memory 
management. 


VS SGA_TARGET_ADVICE 


Displays information that helps vou tune SGA_ 
TARGET. 


VS PGA_TJmGET_ADVICE 


Displays information that helps vou tune PGA_ 
AGGREGATE_TARGET. 



See Also: Oracle Database Rejerence for detaUed information on 
memory management views. 
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Managing Users and Securing the Database 



In this chapter: 

The Importance of Establishing a Security' Policy for Your Database 
Managing Users and Resources 
Managing User Privileges and Roles 
Auditing Database Use 
Predefined User Accounts 

The Importance of Establishing a Security Policy for Your Database 

It is important to develop a securitv policv for ever}' database. The securit\' policy 
establishes methods for protecting vour database from accidental or malicious 
destruction of data or damage to the database infrastructure. 

Each database can have an administrator, referred to as the security administrator, 
who is responsible for implementing and maintaining the database securitv policv If 
the database svstem is small, the database administrator can have the responsibilities 
of the securit\' administrator However, if the database system is large, a designated 
person or group of people mav have sole responsibilitv as security administrator. 

For information about establishing securit}" policies for vour database, see Oracle 
Database Security Guide. 

Managing Users and Resources 

To connect to the database, each user must specifv a valid user name that has been 
previously defined to the database. An account must have been established for the 
user, with information about the user being stored in the data dictionary. 

When vou create a database user (account), you specify' the following attributes of the 
user: 

User name 

Authentication method 

Default table space 

Temporary tablespace 

Other table spaces and quotas 

User profile 
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To learn how to create and manage users, see Oracle Database Security Guide. 



Managing User Privileges and Roles 



Privileges and roles are used to control user access to data and the types of SQL 
statements that can be executed. The table that follows describes the three types of 
privileges and roles: 

Type Description 

System privilege A system- defined privilege usually granted only by 

administrators. These privileges allow users to perform specific 
database operations. 

Object privilege A system-defined privilege that controls access to a specific 

object. 

Role A collection of privileges and other roles. Some system-defined 

roles exist, but most are created by administrators. Roles group 
together privileges and other roles, which facilitates the granting 

of multiple privileges and roles to users. 

Privileges and roles can be granted to other users by users who have been granted the 
privilege to do so. The granting of roles and privileges starts at the administrator level. 
At database creation, the administrative user SYS is created and granted all svstem 
privileges and predefined Oracle Database roles. User SYS can then grant privileges 
and roles to other users, and also grant those users the right to grant specific privileges 
to others. 

To learn how to administer privileges and roles for users, see Oracle Database Security/ 
Guide. 



Auditing Database Use 



You can monitor and record selected user database actions, including those performed 
by administrators. There are several reasons whv vou might want to implement 
database auditing. Complete background information and instructions for database 
auditing are found in Oracle Database Security Guide. 



Predefined User Accounts 



Oracle Database includes a number of predefined user accounts. The three types of 
predefined accounts are: 

■ Administrative accounts (SYS, SYSTEM, SYSMAN, and DBSNMP) 

SYS and SYSTEM are described in "About Database Administrator Securit\' and 
Privileges" on page 1-13. SYSMAH is used to perform Oracle Enterprise Manager 
administration tasks. The management agent of Enterprise Manager uses the 
DBSNMP account to monitor and manage the database. You must not delete these 
accounts. 

■ Sample schema accounts 

These accounts are used for examples in Oracle Database documentation and 
instructional materials. Examples are HR, SH, and OE, You must unlock these 
accounts and reset their passwords before using them. 

■ Internal accounts. 
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These accounts are created so that individual Oracle Database features or 
components can have their own schemas. You must not delete internal accounts, 
and you must not attempt to log in with them. 

See Also: Oracle Database 2 Day + Security Guide for a table of 
predefined accounts. 
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Monitoring Database Operations 



It is important tliat vou monitor tlie operation of your database on a regular basis. 
Doing so not only informs vou of errors tliat liave not yet come to vour attention but 
also gives vou a better understanding of the normal operation of vour database. Being 
fiimiliar with normal behavior in turn helps vou recognize when something is wrong. 

In this chapter: 

■ Monitoring Errors and Alerts 

■ Monitoring Performance 



Monitoring Errors and Alerts 



The following sections explain how to monitor database errors and alerts. It contains 
the following topics: 

■ Monitoring Errors with Trace Files and the Alert Log 

■ Monitoring with Server-Generated Alerts 

Note: The easiest and best way to monitor the database for errors 
and alerts is with the Database Home page in Enterprise Manager. 
This section provides alternate methods for monitoring, using data 
dictionary views, PL/SQL packages, and other command-line 
facilities. 

Monitoring Errors with Trace Files and the Alert Log 

Each server and background process can write to an associated h^ce file. When an 
internal error is detected by a process, it dumps information about the error to its trace 
file. Some of the information written to a trace file is intended for the database 
administrator, and other information is for Oracle Support Services. Trace file 
information is also used to tune applications and instances. 

Note: Critical errors also create incidents and incident dumps in the 
Automatic Diagnostic Repositon'. See Chapter S, "Managing 
Diagnostic Data" on page 8-1 for more information. 

The alert log is a chronological log of messages and errors, and includes the following 
items: 
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■ All internal errors (OEA-5 0), block corruption errors (ORA-157 8), and deadlock 
errors (OEA- 6 O) that occur 

■ Administrative operations, such as CREATE, ALTEE, and DEOP statements and 

STAETUP, SHUTDOWN, and ARCHIVELOG statements 

■ Messages and errors relating to the functions of shared server and dispatcher 
processes 

■ Errors occurring during the automatic refresh of a materialized view 

■ The values of all initialization parameters that had nondefault values at the time 
the database and instance start 

Oracle Database uses the alert log to record these operations as an alternative to 
displaving the information on an operator's console (although some svstems also 
displav information on the console). If an operation is successful, a "completed" 
message is written in the alert log, along with a timestamp. 

The alert log is maintained as both an XML-formatted file and a text-formatted file. 
You can view either format of the alert log with anv text editor or you can use the 
ADRCl utility to view the XML-formatted version of the file with the XML tags 
stripped. 

Check the alert log and trace files of an instance periodicallv to learn whether the 
background processes have encountered errors. For example, when the log writer 
process (LGWR) cannot write to a member of a log group, an error message indicating 
the nature of the problem is written to the LGWR trace file and the alert log. Such an 
error message means that a media or I/O problem has occurred and should be 
corrected immediately. 

Oracle Database also writes values of initialization parameters to the alert log, in 
addition to other important statistics. 

The alert log and all trace files for background and server processes are written to the 
Automatic Diagnostic Repository, the location of which is specified by the 
DIAGWOSTIC_DEST initialization parameter. The names of trace files are operating 
system specific, but each file usually includes the name of the process writing the file 
(such as LGWR and RECO), 

See Also: 

■ Chapter 8, "Managing Diagnostic Data" on page 8-1 for 
information on the Automatic Diagnostic Repository. 

■ "Alert Log" on page 8-5 for additional information about the 
alert log. 

■ "Viewing the Alert Log" on page 8-18 

■ Oracle Database Utilities for information on the ADRCI utility. 

■ Your operating system specific Oracle documentation for 
information about the names of trace files 

Controlling the Size of Trace Files 

You can control the maximum size of aU trace files (excluding the alert log) using the 
initialization parameter MAX_DUMP_E I LE_S I ZE. which limits the file to the specified 
number of operating system blocks. To control the size of an alert log, vou must 
manually delete the file when you no longer need it Otherwise the database continues 
to append to the file. 
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YoLL can safelv delete the alert log while the instance is running, although vou should 
consider making an archived copy of it first. This archived copv could prove valuable 
if you should have a future problem that requires investigating the history of an 
instance. 

Controlling When Oracle Database Writes to Trace Files 

Background processes always write to a trace file when appropriate. In the case of the 
ARC); background process, it is possible, through an initialization parameter, to 
control the amount and t\'pe of trace information that is produced. This behavior is 
described in "Controlling Trace Output Generated bv the Archivelog Process" on 
page 11-13. Other background processes do not have this fiexibihty. 

Trace files are written on behalf of ser\'er processes whenever critical errors occur. 
Additionally, setting the initialization parameter SQL_TRACE = TRUE causes the SQL 
trace facilit\' to generate performance statistics for the processing of all SQL statements 
for an instance and write them to the Automatic Diagnostic Repository. 

Optionally, you can request that trace files be generated for sen'er processes. 
Regardless of the current value of the SQL_TRACE initialization parameter, each 
session can enable or disable trace logging on behalf of the associated server process 
by using the SQL statement ALTER SESSION SET SQL_TRACE. This example 
enables the SQL trace facility for a specific session: 

ALTER SESSION SET SQL_TRACE TRUE; 

Use theDBMS_SESSIONor the DBMS_MONITOR packagesif you want to control SQL 
tracing for a session. 



Caution: The SQL trace facilit}' for server processes can cause 
significant system o\'erhead resulting in severe performance 
impact, so you should enable this feature only when collecting 
statistics. 



See Also: 

■ Chapter 8, "Managing Diagnostic Data" on page 8-1 for more 
information on how the database handles critical errors, 
otherwise known as "incidents," 

Reading the Trace File for Shared Server Sessions 

If shared server is enabled, each session using a dispatcher is routed to a shared sen'er 
process, and trace information is written to the server trace file only if the session has 
enabled tracing (or if an error is encountered). Therefore, to track tracing for a specific 
session that connects using a dispatcher, vou might have to explore several shared 
ser\er trace files. To help vou, Oracle provides a command line utilit\' program, 
treses s, which consolidates all trace information pertaining to a user session in one 
place and orders the information by time. 

See Also: Ornclc Database PcTformaua: Tuning Guide for 
information about using the SQL trace facilit\' and using TKPROF 
and tr c E e E E to interpret the generated trace files 
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Monitoring with Server-Generated Alerts 

A server- genera ted alert is a notification from tfie Oracle Database server of an 
impending problem. The notification mav contain suggestions for correcting the 
problem. Notifications are also provided when the problem condition has been 
cleared. 

Alerts are automatically generated when a problem occurs or when data does not 
match expected values for metrics, such as the following: 

■ Ph\'sical Reads Per Second 

■ User Commits Per Second 

■ SQL Service Response Time 

Server- generated alerts can be based on threshold levels or can issue simply because 
an event has occurred. Threshold- based alerts can be triggered at both threshold 
warning and critical levels. The value of these levels can be customer- defined or 
internal values, and some alerts have default threshold levels which you can change if 
appropriate. For example, by default a server- genera ted alert is generated for 
tablespace space usage when the percentage of space usage exceeds either the 85% 
warning or 97*'b critical threshold level. Examples of alerts not based on threshold 
levels are: 

■ Snapshot Too Old 

■ Resumable Session Suspended 

■ Recovery Area Space Usage 

An alert message is sent to the predefined persistent queue ALERT_QUE owned bv the 
user SYS. Oracle Enterprise Manager reads this queue and provides notifications 
about outstanding server alerts, and sometimes suggests actions for correcting the 
problem. The alerts are displayed on the Enterprise Manager Database Home page 
and can be configured to send email or pager notifications to selected administrators. 
If an alert cannot be written to the alert queue, a message about the alert is written to 
the Oracle Database alert log. 

Background processes periodically flush the data to the Automatic Workload 
Repositorv to capture a histor}' of metric values. The alert histor}' table and ALERT_ 
QUE are purged automatically by the system at regular intervals. 

Setting and Retrieving Thresholds for Server-Generated Alerts 

You can view and change threshold settings for the server alert metrics using the SET_ 

THRESHOLD and GET_THRESHOLD procedures of the DBMS_SERVER_ALERTS 

PL /SQL package. Examples of using these procedures are provided in the following 
sections: 

■ Setting Threshold Levels 

■ Retrieving Threshold Information 

Note: The most convenient way to set and retrieve threshold values 
is to use the graphical interface of Enterprise Manager See Oracle 
Database 2 Day DBA for instructions. 

See Also: Oracle Database PL/SQL Packages and Types Reference for 
information about the DBMS_SERVER_ALERTS package 
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Setting Threshold Levels The followmg example shows how to set thresholds with the 
SET_THRESHOLD procedure for CPU time for each user call for an instance: 

DBMS_SBRVER_ALBRT . SET_THHBSHOLD { 

DBMS_SESVER_ALEST . CPO_TIME_PER_CALL , DBMS_SERVER_ALEaiT . OPERAT0R_GE , '8000', 
DBMS_SE3iVER_ALERT.0PERAT0R_GE, '10000', 1, 2, 'instl', 
DBMS_SE»VER_ALERT.OBJECT_T¥PE_SERVICE, 'inairi.regreES.rdbins.dev.us.oracle.com') ; 

In this example, a warning alert is issued when CPU time exceeds 8000 microseconds 
for each user call and a critical alert is issued when CPU time exceeds 10,000 
microseconds for each user call. The arguments include: 

■ CPU_TIME_PER_CALL specifies the metric identifier For a list of support metrics, 
see Oracle Database PL/SQL Packages and Types Reference. 

■ The observation period is set to 1 minute. This period specifies the number of 
minutes that the condition must deviate from the threshold value before the alert 
is issued. 

■ The number of consecutive occurrences is set to 2. This number specifies how 
manv times the metric value must violate the threshold values before the alert is 
generated. 

■ The name of the instance is set to instl, 

■ The constant DBMS_ALERT . OBJECT_TYPE_SERVICE specifies the object type on 
which the threshold is set. In this example, the service name is 

main . r egr es s . r dbms . dev . us . or acle . com. 

Retrieving Threshold Information To retrieve threshold values, use the GET_THRESHOLD 
procedure. For example: 

DECLftRE 

waming_operator BIHARY_IHTEGER ; 

warning_value VARCHAR2 (60) ; 

critical_operator BIMARYJNTEGER; 

critical_value VARCHAR2 (60) ; 

observation_period BINARY_INTEGER,- 

consecutive_occurrences BINARY_INTEGER,- 
EEGIH 

DBMS_SERVER_ALERT . GET_THHESHOIJ) ( 

DBHS_SERVER_ALERT.CPO_TIME_PER_CALL, warning_operator, warriing_value, 
critical_operator, critical_value, observationjeriod, 
consecutive_occurrences, 'instl' , 

DBHS_SERVER_ALERT.OBJECT_TYPE_SERVICE, 'inairi.regress.rdbins.dev.us.oracle.com') ; 



[ Warning operator: 

[ Warning value: 

[ Critical operator: 

[ Critical value: 

[ Observation_period: 

' Consecutive occurrences: 



warning_operator) ; 
warning_value} ; 
critical_operator } ; 
critical_value) ; 
observation_period) ; 
consecutive occurrences) 



DBHS_OUTPUT . PUT_LIHE ( 

DBHS_OUTPUT . PUT_LIHE ( 

D™S_0UTPUT . PUT_LIHE ( 

DBMSJUTPUT . PUT_LIHE ( 

DBMS_OUTPUT . PUT_LIHE ( 

DBMS_OUTPOT.POT_LIHE( 
EHD; 
/ 

You can also check specific threshold settings with the DBA_THRESHOLDS view. For 
example: 

SELECT metrics_name, warning_value, critical_value, consecutive_occurrences 
FROM DBA_THRESHOLDS 
WHERE metrics name LIKE ' %CPU Time% ' ; 
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Viewing Server-Generated Aierts 

The easiest way to view server- genera ted alerts is bv accessing the Database Home 
page of Enterprise Manager The following discussion presents other methods of 
viewing these alerts. 

If vou use your own tool rather than Enterprise Manager to display alerts, vou must 
subscribe to the ALERT_QUE, read the ALERT_QUE, and display an alert notification 
after setting the threshold levels for an alert. To create an agent and subscribe the 

agent to the ALERT_QUE, use the CREATE_AQ_AGENT and ADD_3UB3CRIBER 

procedures of the DBMS_AQADM package. 

Next you must associate a database user with the subscribing agent, because onfv a 
user associated with the subscribing agent can access queued messages in the secure 
ALERT_QUE. You must also assign the enqueue privilege to the user Use the ENAELE_ 

DB_ACCESS and GRANT_QUEUE_PRIVILEGE procedures of the DBMS_AQADM 

package. 

Optionallv, vou can register with the DBMS_AQ .REGISTER procedure to receive an 
asynchronous notification when an alert is enqueued to ALERT_QUE. The notification 
can be in the form of emaU, HTTP post, or PL /SQL procedure. 

To read an alert message, vou can use the DBMS_AQ . DEQUEUE procedure or 
OCIAQDeq call. After the message has been dequeued, use the DBMS_SERVER_ 
ALERT . EXPAJiD_ME33AGE procedure to expand the text of the message. 

See Also: Ornclc Database PL/SQL Packages and Types Reference for 
information about the DBMS_AQ, and DBMS_AQADM packages 

Server-Generated Alerts Data Dictionary Views 

The following data dictionarv views provide information about server- genera ted 
alerts. 

View Description 

DBA_THRES HOLDS Lists the threshold settings defined for the instance 

DBA_OUTSTANDING_ALERTS Describes the outstanding alerts in the database 

DBA_ALERT_HISTORY Lists a histoiy of alerts that have been cleared 

VSALERT_TYPES Provides information such as group and type for each alert 

VSMETRICHAME Contains the names, identifiers, and other information 

about the system metrics 

VSMETRIC Contains system-level metric values 

VSMETRIC_HISTORY Contains a historv of svstem-level metric values 



See Also: Oracle Database Rejerence for information on static data 
dictionary views and dynamic performance views 
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Monitoring database performance is covered in detail in Oracle Database Performance 
Tuning Guide. Here are some additional topics with details that are not covered in that 
guide: 

■ Monitoring Locks 

■ Monitoring Wait Events 
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Monitoring Locks 



Locks are mechanisms that prevent destructive interaction between transactions 
accessing ttie same resource. The resources can be either user objects, such ns tables 
and rows, or system objects not visible to users, such as shared data structures in 
memor\' and data dictionary rows. Oracle Database automatically obtains and 
manages necessar;' locks when executing SQL statements, so you need not be 
concerned with such details. However, the database also lets you lock data manually. 

A deadlock can occur when two or more users are waiting for data locked bv each 
other. Deadlocks prevent some transactions from continuing to work. Oracle Database 
automatically detects deadlock situations and resolves them bv rolling back one of the 
statements involved in the deadlock, thereby releasing one set of the conflicting row 
locks, 

Oracle Database is designed to avoid deadlocks, and they are not common. Most often 
they occur when transactions explicitly override the default locking of the database. 
Deadlocks can affect the performance of your database, so Oracle provides some 
scripts and views that enable you to monitor locks. 

The utllockt . sql script displays, in a tree fashion, the sessions in the system that 
are waiting for locks and the locks that they are waiting for The location of this script 
file is operating system dependent. 

A second script, catblock. sql, creates the lock views that utllockt . sql needs, so 
you must run it before running utllockt . aql. 

See Also: 

■ "Performance Monitoring Data Dictionary Views" on page 7-7 

■ Oracle Database Concepts contains more information about locks. 



Monitoring Wait Events 

Wait events are statistics that are incremented by a server process to indicate that it 
had to wait for an event to complete before being able to continue processing. A 
session could wait for a variety of reasons, including waiting for more input, waiting 
for the operating system to complete a service such as a disk write, or it could wait for 
a lock or latch. 

When a session is waiting for resources, it is not doing any useful work. A large 
number of waits is a source of concern. Wait event data reveals various symptoms of 
problems that might be affecting performance, such as latch contention, buffer 
contention, and I/O contention. 

Oracle provides several views that display wait event statistics. A discussion of these 
views and their role in instance tuning is contained in Oiade Database Performance 
Tuning Guide. 

Performance Monitoring Data Dictionary Views 

This section lists some of the data dictionary views that you can use to monitor an 
Oracle Database instance. These views are general in their scope. Other views, more 
specific to a process, are discussed in the section of this book wliere the process is 
described. 
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View 


Description 


VSLOCK 


Lists the locks currently held by Oracle Database and outstanding 
requests for a lock or latch 


DBA_BLOCKERS 


Displays a session if it is holding a lock on an object tor which 

another session is waiting 


DBA_WAITERS 


Displays a session if it is waiting for a locked object 


DBA_DDL_LOCKS 


Lists all DDL locks held in the database and all outstanding 
requests for a DDL lock 


DBA_DML_LOCKS 


Lists all DML locks held in the database and all outstanding 
requests for a DML lock 


DBA_LOCK 


Lists all locks or latches held in the database and all outstanding 
requests for a lock or latch 


DBA_LOCK_IHTEEMAL 


Displays a row for each lock or latch that is being held, and one 
row for each outstanding request for a lock or latch 


VS LOCKED_OB JECT 


Lists all locks acquired by every transaction on the system 


VSSESSIOH_WAIT 


Lists the resources or events for which active sessions are waiting 


VS SYS STAT 


Contains session statistics 


VS RES OURCE_LIMI T 


Provides information about current and maximum global resource 
utilization for some system resources 


VSSQLAREA 


Contains statistics about shared SQL area and contains one row for 
each SQL string. Also provides statistics about SQL statements that 
are in memory, parsed, and ready for execution 


VS LATCH 


Contains statistics tor nonparent latches and summary statistics for 
parent latches 



See Also: Oracle Database Reference for detailed descriptions of 
these views 
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Managing Diagnostic Data 



Beginning with Release 11^, Oracle Database includes an advanced fault 
diagnosabilit\" infrastructure for collecting and managing diagnostic data. Diagnostic 
data includes the trace files, dumps, and core files that are also present in previous 
releases, plus new types of diagnostic data that enable customers and Oracle Support 
to identify, investigate, track, and resolve problems quicklv and effectively. 

In this chapter: 

About the Oracle Database Fault Diagnosabilitv Infrastructure 

Investigating, Reporting, and Resolving a Problem 

Viewing Problems with the Enterprise Manager Support Workbench 

Creating a User-Reported Problem 

Viewing the Alert Log 

Finding Trace Files 

Running Health Checks w^ith Health Monitor 

Repairing SQL Failures with the SQL Repair Advisor 

Repairing Data Corruptions with the Data Recover\' Advisor 

Creating, Editing, and Uploading Custom Incident Packages 

About the Oracle Database Fault Diagnosability Infrastructure 

This section contains background information on the Oracle Database fault 
diagnosabilify infrastructure. It contains the following topics: 

■ Fault Diagnosability Infrastructure Overview 

■ About Incidents and Problems 

■ Fault Diagnosability Infrastructure Components 

■ Structure, Contents, and Location of the Automatic Diagnostic Repository 

Fault Diagnosability Infrastructure Overview 

The fault diagnosabilify infrastructure aids in preventing, detecting, diagnosing, and 
resolving problems. The problems that are targeted in particular are critical errors 
such as those caused by database code bugs, metadata corruption, and customer data 
corruption. 
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When a critical error occurs, it is assigned an incident number, and diagnostic data for 
the error (such as trace files) are inimediatelv captured and tagged with this number. 
The data is then stored in the Automatic Diagnostic Repositor}' (ADR) — a file-based 
repository outside the database — where it can later be retrieved by incident number 
and analyzed. 

The goals of the fault diagnosabUity infrastructure are the following: 

First-failure diagnosis 

Problem prevention 

Limiting damage and interruptions after a problem is detected 

Reducing problem diagnostic time 

Reducing problem resolution time 

Simplifying customer interaction with Oracle Support 
The keys to achieving these goals are the following technologies; 

■ Automatic capture o£ diagnostic data upon first failure — For critical errors, the 
abilit}' to capture error information at first-failure greatly increases the chance of a 
quick problem resolution and reduced downtime. An always-on memory-based 
tracing svstem proactively collects diagnostic data from many database 
components, and can help isolate root causes of problems. Such proactive 
diagnostic data is similar to the data collected by airplane "black box" flight 
recorders. When a problem is detected, alerts are generated and the fault 
diagnosabilit}' infrastructure is activated to capture and store diagnostic data. The 
data is stored in a repository that is outside the database (and therefore available 
when the database is down), and is easilv accessible with command line utilities 
and Enterprise Manager. 

■ Standardized trace formats — Standardizing trace formats across all database 
components enables DBAs and Oracle Support personnel to use a single set of 
tools for problem analysis. Problems are more easilv diagnosed, and downtime is 
reduced. 

■ Health checks — Upon detecting a critical error, the fault diagnosability 
infrastructure can run one or more health checks to perform deeper analysis of a 
critical error. Health check results are then added to the other diagnostic data 
collected for the error Individual health checks look for data block corruptions, 
undo and redo corruption, data dictionary corruption, and more. As a DBA, you 
can manually invoke these health checks, either on a regular basis or as required. 

■ Incident packaging service (IPS) and incident packages — The IPS enables you to 
automatically and easily gather the diagnostic data — traces, dumps, health check 
reports, and more — pertaining to a critical error and package the data into a zip 
file for transmission to Oracle Support. Because all diagnostic data relating to a 
critical error are tagged with that error's incident number, you do not have to 
search through trace files and other files to determine the files that are required for 
analysis; the incident packaging service identifies the required files automatically 
and adds them to the zip file. Before creating the zip file, the IPS first collects 
diagnostic data into an intermediate logical structure called an incident package 
(package). Packages are stored in the Automatic Diagnostic Repository. If you 
choose to, you can access this intermediate logical structure, view and modify its 
contents, add or remove additional diagnostic data at anv time, and when you are 
readv, create the zip file from the package and upload it to Oracle Support. 

■ Data Recovery Advisor — The Data Recovery Advisor integrates with database 
health checks and RMAN to display data corruption problems, assess the extent of 



8-2 Oracle Database Administrator's Guide 



About the Oracle Dalabase Fault DIagnosabillty Infrastructure 



each problem (critical, high priority, low priorit}'), describe the impact of a 
problem, recommend repair options, conduct a feasibility check of the 
customer-chosen option, and automate the repair process. 

■ SQL Test Case Builder — For many SQL-related problems, obtaining a 

reproducible test case is an important factor in problem resolution speed. The SQL 
Test Case Builder automates the sometimes difficult and time-consuming process 
of gathering as much information as possible about the problem and the 
en\'ironment in which it occurred. After quicklv gathering this information, vou 
can upload it to Oracle Support to enable support personnel to easily and 
accurately reproduce the problem. 

See Also: 

■ Oracle Database Performance Tuning Guide for more information on 
SQL Test Case Builder 

About Incidents and Problems 

To facilitate diagnosis and resolution of critical errors, the fault diagnos ability 
infrastructure introduces two concepts for Oracle Database: problems and incidents. 

A problem is a critical error in the database. Critical errors manifest as internal errors, 
such as ORA-00600, or other severe errors, such as ORA-0744 5 (operating system 
exception) or ORA-04031 (out of memory in the shared pool). Problems are tracked in 
the ADR. Each problem has a problem key, which is a text string that describes the 
problem. It includes an error code (such as ORA 6 0) and in some cases, one or more 
error parameters. 

An incident is a single occurrence of a problem. When a problem (critical error) occurs 
multiple times, an incident is created for each occurrence. Incidents are timestamped 
and tracked in the Automatic Diagnostic Repository (ADR). Each incident is identified 
by a numeric incident ID, which is unique within the ADR. When an incident occurs, 
the database: 

Makes an entry in the alert log. 

Sends an incident alert to Oracle Enterprise Manager (Enterprise Manager). 

Gathers first-failure diagnostic data about the incident in the form of dump files 
(incident dumps). 

Tags the incident dumps with the incident ID. 

Stores the incident dumps in an ADR subdirector}' created for that incident. 

Diagnosis and resolution of a critical error usually starts with an incident alert. The 
incident alert is displayed on the Enterprise Manager Database Home page. You can 
then yiew the problem and its associated incidents with Enterprise Manager or with 
the ADRCl command-line utility. 

Incident Flood Control 

It is conceiyable that a problem could generate dozens or perhaps hundreds of 
incidents in a short period of time. This would generate too much diagnostic data, 
which would consume too much space in the ADR and could possibly slow down 
your efforts to diagnose and resolve the problem. For these reasons, the fault 
diagnosabilit}' infrastructure applies/Zooii control to incident generation after certain 
thresholds are reached, A flood-controlled incident is an incident that generates an 
alert log entry, is recorded in the ADR, but does not generate incident dumps. 
Flood-controlled incidents provide a way of informing you that a critical error is 
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ongoing, without overloiiding tlie system with diagnostic data. You can choose to 
view or hide flood-controlled incidents when viewing incidents with Enterprise 
Manager or ADRCI. 

Threshold levels for incident flood control are predetermined and cannot be changed. 
Thev are defined as follows: 

■ After five incidents occur for the same problem key in one hour, subsequent 
incidents for this problem key are flood-controlled. Normal (non-flood-controlled) 
recording of incidents for that problem key begins again in the next hour. 

■ After 25 incidents occur for the same problem key in one dav, subsequent 
incidents for this problem key are flood -controlled. Normal recording of incidents 
for that problem kev begins again on the next day. 

In addition, after 50 incidents for the same problem kev occur in one hour, or 250 
incidents for the same problem key occur in one dav, subsequent incidents for this 
problem key are not recorded at all in the ADR, In these cases, the database writes a 
message to the alert log indicating that no further incidents will be recorded. As long 
as incidents continue to be generated for this problem kev, this message is added to 
the alert log every ten minutes until the hour or the day expires. Upon expiration of 
the hour or dav, normal recording of incidents for that problem key begins again. 

See Also: 

■ "Viewing Problems with the Enterprise Manager Support 
Workbench" on page 8-16 

■ "Investigating, Reporting, and Resolving a Problem" on page 8-9 

■ "ADRCI Com.mand-Line Utilit;'" on page 8-6 

Fault Diagnosability Infrastructure Components 

The following are the key components of the fault diagnosability infrastructure: 
Automatic Diagnostic Repository (ADR) 
Alert Log 

Trace Files, Dumps, and Core Files 
Other ADR Contents 
Enterprise Manager Support Workbench 
ADRCI Command-Line Utility 

Automatic Diagnostic Repository (ADR) 

The ADR is a file-based repository for database diagnostic data such as traces, dumps, 
the alert log, health monitor reports, and more. It has a unified director}' structure 
across multiple instances and multiple products. Beginning with Release llg, the 
database, Automatic Storage Management (ASM), and other Oracle products or 
components store all diagnostic data in the ADR, Each instance of each product stores 
diagnostic data underneath its own home directory within the ADR, For example, in 
an Oracle Real Application Clusters environment with shared storage and ASM, each 
database instance and each ASM instance has an ADR home directory. ADR's unified 
directory structure, consistent diagnostic data formats across products and instances, 
and a unified set of tools enable customers and Oracle Support to correlate and 
analyze diagnostic data across multiple instances. 
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Note: Beginning with Release llg of Oracle Database, because all 
diagnostic data, including the alert log, are stored in the ADR, the 
initialization parameters BACKGROUND_DUMP_DEST and USER_ 
DUMP_DEST are deprecated. They are replaced by the initialization 
parameter DIAGNOSTIC_DEST, which identifies the location of the 
ADR. 



See Also: "Structure, Contents, and Location of the Automatic 
Diagnostic Repositorj'" on page 8-6 for more information on the 
DiaGNOSTIC_DEST parameter and on ADR homes. 

Alert Log 

The alert log is an XML file that is a chronological log of database messages and errors. 
It is stored in the ADR and includes messages about the following: 

■ Critical errors (incidents) 

■ Administrative operations, such as starting up or shutting down the database, 
recovering the database, creating or dropping a tablespace, and others. 

■ Errors during automatic refresh of a materialized view 

■ Other database events 

You can view the alert log in text format (with the XML tags stripped) with Enterprise 
Manager and with the ADRCI utilitv. There is also a text-formatted version of the alert 
log stored in the ADR for backward compatibilit\'. However. Oracle recommends that 
anv parsing of the alert log contents be done with the XML-formatted version, because 
the text format is unstructured and mav change from release to release. 

See Also: 

■ "ADRCI Command-Line Utilit;'" on page 8-6 

■ "Viewing the Alert Log" on page 8-18 

Trace Files, Dumps, and Core Files 

Trace files, dumps, and core files contain diagnostic data that are used to investigate 
problems. They are stored in the ADR, 

Trace Files Each server and background process can write to an associated trace file. 
Trace files are updated periodicallv over the life of the process and can contain 
information on the process environment, status, activities, and errors. In addition, 
when a process detects a critical error, it writes information about the error to its trace 
file. The SQL trace facility also creates trace files, which provide performance 
information on individual SQL statements. You can enable SQL tracing for a session or 
an instance. 

Trace file names are platform-dependent. Typically, database background process 
trace file names contain the Oracle SID, the background process name, and the 
operating system process number, while server process trace file names contain the 
Oracle SID, the string "ora", and the operating system process number The file 
extension is . trc. An example of a sender process trace file name is orcl_ora_344.trc. 
Trace files are sometimes accompanied by corresponding trace map ( . trm) files, 
which contain structural information about trace files and are used for searching and 
navigation. 
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Oracle Database includes tools that help vou analvze trace files. For more information 
on application tracing, SQL tracing, and tracing tools, see Oracle Database Performance 
Tuning Guide. 

See Also: "Finding Trace FUes" on page 8-19 

Dumps A dump is a specific type of trace file. A dump is typically a one-time output of 
diagnostic data in response to an event (such as an incident), whereas a trace tends to 
be continuous output of diagnostic data. When an incident occurs, the database writes 
one or more dumps to the incident directon' created for the incident. Incident dumps 
also contain the incident number in the file name. 

Core Files A core file contains a memorv dump, in an all-binary, port-specific format. 
Core file names include the string "core" and the operating system process ID, Core 
files are useful to Oracle Support engineers onJv. Core files are not found on all 
platforms. 

Other ADR Contents 

In addition to files mentioned in the previous sections, the ADR contains health 
monitor reports, data repair records, SQL test cases, incident packages, and more. 
These components are described later in the chapter. 

Enterprise Manager Support Workbench 

The Enterprise Manager Support Workbench (Support Workbench) is a facility' that 
enables vou to investigate, report, and in some cases, repair problems (critical errors), 
all with an easy-to-use graphical interface. The Support Workbench provides a 
self-service means for vou to gather first-failure diagnostic data, obtain a support 
request number, and upload diagnostic data to Oracle Support with a minimum of 
effort and in a \'ery short time, thereby reducing time-to-resolution for problems. The 
Support Workbench also recommends and provides easy access to Oracle advisors 
that help you repair SQL-related problems, data corruption problems, and more, 

ADRCI Command-Line Utility 

The ADR Command Interpreter (ADRCI) is a utility that enables vou to investigate 
problems, view health check reports, and package and upload first-failure diagnostic 
data to Oracle Support, all within a command-line environment, ADRCI also enables 
vou to view the names of the trace files in the ADR, and to view the alert log with 
XML tags stripped, with and without content filtering. 

For more information on ADRCI, see Oracle Database Utilities. 

Structure, Contents, and Location of the Automatic Diagnostic Repository 

The Automatic Diagnostic Repository (ADR) is a directory structure that is stored 
outside of the database. It is therefore available for problem diagnosis when the 
database is down. 

The ADR root directory is known as ADR base. Its location is set by the 
DIAGNOSTIC_DEST initialization parameter If this parameter is omitted or left null, 
the database sets DIAGNOSTIC_DEST upon startup as follows: 

■ If environment variable ORACLE_BASE is set, DIAGNOSTIC_DEST is set to the 
directory designated by ORACLE_BASE, 

■ If environment variable ORACLE_BASE is not set, DIAGNGSTIC_DEST is set to 
ORACLE_HOME / log, 
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Within ADR base, there can be multiple ADR homes, where each ADR home is the 
root directory for all diagnostic data — traces, dumps, the alert log, and so on — for a 
particular instance of a particular Oracle product or component. For example, in an 
Oracle Real Application Clusters environment with ASM, each database instance and 
each ASM instance has an ADR home. All ADR homes share the same hierarchical 
directory structure. 

The location of an ADR home is given bv the following path, which starts at the ADR 
base director^': 

diag/product_type/product_id/instdnce_id 

Table 8-1 lists the values of the various path components for an Oracle Database 
instance. 

Table 8-1 ADR Home Path Components for Oracle Database 



Path Component Value for Oracle Database 



product_tvpe 


rdbms 


producMd 


database nnme 


instance id 


SJD 



For example, for a database with a SID and database name both equal to orcibi, the 
ADR home would be in the following location: 

,flQR_fcase / d i a g / r diims / or c lb i / or c lb i / 

ADR Home Subdirectories 

Within the ADR home directorv are subdirectories where the database instance stores 
diagnostic data. Table 8-2 lists some of these subdirectories and their contents. 

Table 8-2 ADR Home Subdirectories 
Subdirectory Name Contents 

alert The XML-formatted alert log 

cdump Core files 

incident Multiple subdirectories, where each subdirectory is 

named for a particular incident, and where each contains 
dumps pertaining only to that incident 

trace Background and server process trace files and SQL trace 

files 

(others) Other subdirectories of ADR home, which store incident 

packages, health monitor reports, and other information 

Figure 8-1 illustrates the director^' hierarchy of the ADR for an Oracle Database 
instance. Other ADR homes for other Oracle products or components (such as ASM or 
Oracle Net Ser\'ices) can exist within this hierarchy, under the same ADR base. 
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Figure 8-1 ADR Directory Structure for an Oracle Database Instance 
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ADR in an Oracle Real Application Clusters Environment 

In an Oracle Real Application Clusters (RAC) environment, each node can have ADR 
base on its own local storage, or ADR base can be set to a location on shared storage. 
The following are the advantages of the shared storage approach; 

■ You can use ADRCI to view aggregated diagnostic data from all instances on a 
single report. 

■ You can use the Data Recovery Advisor to help diagnose and repair corrupted 
data blocks, corrupted or missing files, and other data failures. (For Oracle RAC, 
the Data Recoverv Advisor requires shared storage.) 

See Oracle Database 2 Day DBA for more information on tlie Data Recovery 
Advisor. 

Viewing ADR Locations with the VSDIAG_INFO View 

The VSDIAG_INFO view lists all important ADR locations for the current Oracle 
Database instance. 



SELECT ' FROM VSDIAG_INFO; 



IH3T ID BAHE 



VALUE 



1 Diag Enabled 

1 ADR Base 

1 ADR Home 

1 Diag Trace 

1 Diag Alert 

1 Diag Incident 

1 Diag Cdump 

1 Health Monitor 

1 Default Trace File 

1 Active Problem Count 

1 Active Incident Count 



TRDE 

/uOl/ oracle 

/uOl/ oracle/ diag/ rdbms/ ore Ibi/ ore Ibi 

/uOl/ oracle /diag/ rdbms /orclbi/ ore Ibi/ trace 

/uOl/ oracle /diag/ rdbms /orelbi/ ore Ibi /alert 

/uOl/ oracle /diag/ rdbms /orelbi/ ore Ibi /incident 

/uOl/ oracle /diag/ rdbms /orclbi/ ore Ibi /cdump 

/uQl/ oracle /diag/ rdbms /orelbi/ ore Ibi /hm 

/n01/oracle/diag/rdbmE/orclbi/orclbi/trace/orcl_ora_22769. trc 



20 



The following table describes some of the information displaved bv this view. 
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Table 8-3 Data in the VSDIAGJNFO View 



Name Description 



ADR Base Path of ADR base 

ADR Home Path of ADR home for the current database instance 

Diag Trace Location of background process trace files, server process trace files, SQL 

trace files, and the text-formatted version of the alert log 

Diag Alert Location of the XML-formatted version of the alert log 

Default Trace File Path to the trace file for the current session 

Investigating, Reporting, and Resolving a Problem 

This section describes how to use the Enterprise Manager Support Workbench 
(Support Workbench) to investigate and report a problem (critical error), and in some 
cases, resolve the problem. The section begins with a "roadmap" that summarizes the 
typical set of tasks that you must perform. 

Note: The tasks described in this section are all Enterprise 
Manager-based, You can also accomplish all of these tasks (or their 
equivalents) with the ADRCI command-line utilit}', with PL/SQL 
packages such as DBMS_HM and DBMS_SQLDIAG, and with other 
software tools. See Oracle Database Utilities for more information on 
the ADRCI utility, and see Oracle Database PL/SQL Packages and Types 
Reference for information on PL/SQL packages. 

See Also: "About the Oracle Database Fault Diagnosability 
Infrastructure" on page 8-1 for more information on problems and 
their diagnostic data 

Roadmap— Investigating, Reporting, and Resolving a Problem 

You can begin investigating a problem by starting from the Support Workbench home 
page in Enterprise Manager. However, the more t\'pical workflow begins with a 
critical error alert on the Database Home page. This section provides an overview of 
that workflow. 

Figure 8-2 illustrates the tasks that you complete to investigate, report, and in some 
cases, resolve a problem. 
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Figure 8-2 Workflow for Investigating, Reporting, and Resolving a Problem 




The following are task descriptions. Subsequent sections provide details for each task. 

■ Task 1 - View Critical Error Alerts in Enterprise Manager on page 8-11 

Start by accessing the Database Home page in Enterprise Manager, and reviewing 
critical error alerts. Select an alert for which to view detaUs, and then go to the 
Problem Details page. 

■ Task 2 -View Problem Details on page 8-12 

Examine the problem details and view a list of all incidents that were recorded for 
the problem. Display findings from any health checks that were automatically run. 

■ Task 3 - (Optional) Gather Additional Diagnostic Information on page 8-12 

Optionally run additional health checks or other diagnostics. For SQL-related 
errors, optionally invoke the SQL Test Case Builder, which gathers all required 
data related to a SQL problem and packages the information in a way that enables 
the problem to be reproduced at Oracle Support. 

■ Task 4 - (Optional) Create a Service Request on page 8-12 

Optionally create a service request ivithOracleMefiiLjufc and record the service 
request number with ttie problem information. If you skip this step, you can create 
a service request later, or the Support Workbench can create one for you. 

■ Task 5 - Package and Upload Diagnostic Data to Oracle Support on page 8-13 

Invoke a guided workflow (a wizard) that automatically packages the gathered 
diagnostic data for a problem and uploads the data to Oracle Support. 

■ Task 6 - Track the Service Request and Implement Any Repairs on page 8-14 

Optionally maintain an activity log for the service request in the Support 
Workbench. Run Oracle advisors to help repair SQL failures or corrupted data. 
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■ Task 7 - Close Incidents on. page 8-lE> 

Set status for one. some, or all incidents for the problem to Closed. 

See Also: "Viewing Problems with the Enterprise Manager Support 
Workbench" on page 8-16 

Task 1 - View Critical Error Alerts in Enterprise Manager 

YoLi begin the process of investigating problems (critical errors) bv reviewing critical 
error alerts on the Database Home page. 

To view critical error alerts: 

1 . Access the Database Home page in Enterprise Manager, 

For Oracle Enterprise Manager Database Control, see Oracle Database 2 Day DBA 
for instructions. For Oracle Enterprise Manager Grid Control, go to the desired 
database target. 

2. In the Alerts section, exam.ine the table of alerts. 

Critical error alerts are indicated by a red x in the Severity column, and the text 
"Incident" in the Category column. 

Note: You mav have to click the hide/show icon next to the Alerts 
heading to display the alerts table. 



Figure 8-3 Alerts Table on the Database Home Page 
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3. In the Message column, click the message of the critical error alert that you want 
investigate. 

The Incident page or Data Failure page appears. This page includes: 

■ Problem information, including the number of incidents for the problem 

■ A Performance and Critical Error graphical timeline for the 24-hour period in 
which the critical error occurred. 

■ Alert details, including severity, timestamp, and message 

■ Controls that enable you to clear the alert or record a comment about it. 

4. Review the Performance and Critical Error graphical timeline, and note any time 
correlation between performance issues and the critical error. Optionally clear the 
alert or leave a comment about it 

5. Do one of the following: 

■ If vou want to view the details of the problem associated w^ith the critical error 
alert that you are investigating, proceed with Task 2 -View Problem Details on 
page 8-12. 
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■ If the graphical timehne shows a large number of different problems over the 
past 24 hours and you want to view a summary of all those problems, 
complete these steps: 

- Chck View Al! Problem.9. 

The Support Workbench home page appears, 

- View problems and incidents as described in 'Viewing Problems with the 
Enterprise Manager Support Workbench " on page 8-16. 

- Select a single problem and view problem details, as described in 
"Viewing Problems with the Enterprise Manager Support Workbench" on 
page 8-16, 

- Continue with either Task 3 - (Optional) Gather Additional Diagnostic 
Information on page 8-12 or Task 4 - (Optional) Create a Service Request 
on page 8-12, 

Task 2 -View Problem Details 

You continue vour investigation writh the Problem DetaUs page. 

To view problem details: 

1. On the Incident page or Data Failure page, click Viewr Problem Details, 

The Problem Details page appears, showing the Incidents subpage. 

2. (Optional) To view incident details, select an incident, and then chck View, 
The incident details page appears, 

3. (Optional) On the Incident Details page, chck Checker Findings to view the 
Checker Findings subpage. 

This page displays findings from any health checks that were automatically run 
when the critical error was detected. 

See Also: "Rurming Health Checks with Health Monitor" on 
page 8-iq 

Task 3 - (Optional) Gather Additional Diagnostic Information 

You can perform the following activities to gather additional diagnostic information 
for a problem. This additional information is then automaticallv included in the 
diagnostic data uploaded to Oracle Support, If you are unsure as to whether or not to 
perform these activities, check with your Oracle Support representative, 

■ Manually invoke additional health checks 

See "Running Health Checks with Health Monitor" on page 8-19 

■ Invoke the SQL Test Case BuUder 

See Oracle Database Performance Timing Guide for instructions. 

Task 4 - (Optional) Create a Service Request 

At this point, vou can create an Oracle Support ser\'ice request and record the ser\'ice 
request number with the problem information. If vou choose to skip this task, the 
Support Workbench will automatically create a draft service request for you in Task 5, 
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To create a service request: 

1. On the Problem Details page, in the Investigate and Resolve section, click Go to 
Metalink, 

The OracleMt'fflL;«jt Login and Registration page appears in a new browser 
window. 



Note: See "Viewing Problems with the Enterprise Manager Support 
Workbench" on page 8-16 for instructions for returning to the Problem 
Details page if you. are not already there. 

2. Log in to OracleMeSaLmk and create a service request in the usual maruier. 
(Optional) Remember the service request number (SR#) for the next step. 

3. (Optional) Return to the Problem Details page, and then do the following: 

a. In the Summar;' section, click the Edit button that is adjacent to the SR# label. 

b. In the window that opens, enter the SR#, and then click OK. 

The SR# is recorded in the Problem Details page. This is for vour reference only. 

Task 5 - Package and Upload Diagnostic Data to Oracle Support 

For this task, you use the quick packaging process of the Support Workbench to 
package and upload the diagnostic information for the problem to Oracle Support. 
Quick packaging has a minimum of steps, organized in a guided workflow (a wizard). 
The wizard assists you with creating an incident package (package) for a single 
problem, creating a zip file from the package, and uploading the file. With quick 
packaging, vou are not able to edit or otherwise customize the diagnostic information 
that is uploaded. However, quick packaging is the more direct, straightforward 
method to package and upload diagnostic data. 

If you want to edit or remove sensitive data from the diagnostic information, enclose 
additional user files (such as application configuration files or scripts), or perform 
other customizations before uploading, vou must use the custom packaging process, 
which is a more manual process and has more steps. See "Creating, Editing, and 
Uploading Custom Incident Packages" on page 8-30 for instructions. If vou choose to 
follow those instructions instead of the instructions here in Task 5, continue with Task 
6 - Track the Service Request and Implement Any Repairs on page 8-14 when you are 
finished. 

Note: The Support Workbench uses Oracle Configuration Manager to 
upload the diagnostic data. If Oracle Configuration Manager is not 
installed or properlv configured, the upload may fail. In this case, a 
message is displaved with a request that vou upload the file to Oracle 
Support manuallv. You can upload manually with OracIeMt'taL/uA:, 

For more information about Oracle Configuration Manager, see Oracle 
Configuration Manager Inifallation and Adiiiiniitraiion Guide. 

To package and upload diagnostic data to Oracle Support: 

1. On the Problem Details page, in the Investigate and Resolve section, click Quick 
Package, 

The Create New Package page of the Quick Packaging wizard appears. 
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Note: See "Viewing Problems with the Enterprise Manager Support 
Workbench" on page 8-16 for instructions for returning to the Problem 
Details page if you are not already there. 
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2. Optionally enter a package name and description, 

3. Fill in the remaining fields on the page. If you already created a service request for 
this problem, select No next to Create new Service Request (SR), 

If vou select Yes, the Quick Packaging wizard creates a draft service request on 
your behalf. You must later log in to OracleAIrfiiLji;/: and fill in the details of the 
service request. 

4. Click Next, and then proceed with the remaining pages of the Quick Packaging 
wizard. 

When the Quick Packaging wizard is complete, the package that it creates remains 
available in the Support Workbench, You can then modifv it with custom 
packaging operations (such as adding new incidents) and reupload at a later time. 
See "Viewing and Modifying Incident Packages" on page 8-36. 

Task 6 - Track the Service Request and Implement Any Repairs 

After uploading diagnostic information to Oracle Support, you might perform various 
activities to track the service request, to collect additional diagnostic information, and 
to implement repairs. Among these activities are the following: 

■ Adding an Oracle bug number to the problem information. 

To do so, on the Problem Details page, click the Edit button that is adjacent to the 
BiLg# label. This is for your reference oiUy, 

■ Adding comments to the problem activiti' log. 

You may want to do this to share problem status or historv information with other 
DBAs in vour organization. For example you could record the results of vour 
conversations with Oracle Support, To add comments, complete the following 
steps: 

1. Access the Problem Details page for the problem, as described in "Viewing 
Problems with the Enterprise Manager Support Workbench" on page 8-16. 
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2. Click Activity Log to display the Activity Log subpage. 

3. In the Comment field, enter a comment, and then click Add Comment. 
Your comment is recorded in the activity log. 

■ As new incidents occur, adding them to the package and reuploading. 

For this activity, you must use the custom packaging method described in 
"Creating, Editing, and Uploading Custom Incident Packages" on page 8-30. 

■ Running health checks. 

See "Running Health Checks with Health Monitor" on page 8-19. 

■ Running a suggested Oracle advisor to implement repairs. 
Access the suggested advisor in one of the following ways: 

- Problem Details page — In the Self-Service tab of the Investigate and Resolve 
section 

- Support Workbench home page — on the Checker Findings subpage 

- Incident Details page — on the Checker Findings subpage 
Table 8-4 lists the advisors that help repair critical errors. 

Table 8-4 Oracle A dvisors that Help Repair Critical Errors 

Advisor Critical Errors Addressed See 

Data Recovery Advisor Corrupted blocks, corrupted or missing files, "Repairing Data Corruptions with 

and other data failures the Data Recovery Advisor" on 

page 8-28 

SQL Repair Advisor SQL statement failures "Repairing SQL Failures with the 

SQL Repair Advisor" on page 8-26 

See Also: "Viewing Problems with the Enterprise Manager Support 
Workbench" on page 8-16 for instructions for viewing the Checker 
Findings subpage of the Incident Details page 



Task 7 - Close Incidents 



When a particular incident is no longer of interest, you can close it, Bv default, closed 
incidents are not displayed on the Problem Details page. 

All incidents, whether closed or not, are purged after 30 davs. You can disable purging 
for an incident on the Incident Details page. 

To close incidents: 

1 . Access the Support Workbench home page. 

See "Viewing Problems with the Enterprise Manager Support Workbench" on 
page 8-16 for instructions. 

2. Select the desired problem, and then cbck Vieiv. 
The Problem Details page appears. 

3. Select the incidents to close and then click Close. 
A confirmation page appears. 

4. Enter an optional comment and click OK, 
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Viewing Problems with the Enterprise IVIanager Support Workbench 

You use the Enterprise Manager Support Workbench home page (Figure 8-4 on 
page 8-16) to view all problems or only those within a specified time period. 

Figure 6-4 Enterprise Manager Support Woridtencb Home Page 



DdldbHi%e In^tdfuie.: cldldbd^p 
Su pport WcirkbBich 



LUOata In fe 5V3TEM 



eP^Frefhsd May l3,2D07ID:&8:iaPMPDT ( RofrBSh ] 



a^t-.r-\ FfdnQ!-fiP^ Fak jne^ f n^ 



New intctrc^ h La^c 21 tur^ 1 1 



Nl Actrvff Prcdcm^ Z 
Al flal^'e IrcCtrC^ II 



AFFrqiblcnc 5 
Al [ndderiG 2i 



ViBhv \l^s\:2AH:-3s I 



](^J MwnzdSgnii 



'. ViQw is P^ckaae 1 




i^-i^iTCill 1 -=h- \rn^ 1 rinDiuAl [feraiS 1 Hcfe AlCe-fli? 






fv^L3, 2(i(i7IO:(i4'23PMPDT 


itai Ijininicnb 


Acin? 


Pothagrd 

Md 


««« 




D t^.^hri-1 2 ORA6DD[dbgtl^flmbPa^e'l] 1 


fv&i. LZ, ZDD7 ll'4L '55 PM PDT 




V£S 


Md 





TPcFfDrniaiKC and Oitlciil Eirot 



12 May 13 
2007 



* QPft 1^79 







■ CPU 

■ UserUO 

■ Wait 


,,.--v. 


nn 


12 m 2 


4 


6 


B 


10 


IZ PM 2 


4 


6 


8 


10 



To access the Support Workbench home page: 

1. Access the Database Home page in Enterprise Manager. 

See Oracle Database 1 Day DBA for the instructions for Oracle Enterprise Manager 
Database Control, For Oracle Enterprise Manager Grid Control, go to the desired 
database target. 

2. Click Software and Support to view the Software and Support page. 

3. In the Support section, click Support Workbench. 

The Support Workbench home page appears, showing the Problems subpage. By 
default the problems from the last 24 hours are displayed. 

4. To view all problems, select All from the View list, 

5. (Optional) If the Performance and Critical Error section is hidden, click the 
Show/Hide icon adjacent to the section heading to show the section. 

This section enables you to view any correlation between performance changes 
and incident occurrences, 

6. (Optional) Under the Details column, click Show^ to display a list of all incidents 
for a problem, and then chck an incident ID to display the Incident Details page. 

To view details lor a particular problem: 

1. On the Support Workbench home page, select the problem, and then click View. 

The Problem Details page appears, showing the Incidents subpage. The incidents 
subpage shows all incidents that are open and that generated dumps — that is, that 
were not flood-controlled. 
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2. (Optional) To view both open and closed incidents, select All Incidents in the 
Status list. To view both normal and flood-controlled incidents, select All 
Incidents in the Data Dumped list. 

3. (Optional) To view details for an incident, select the incident, and then click View. 
The Incident Details page appears. 

4. (Optional) On the Incident Details page, to view checker findings for the incident, 
click Checker Findings. 

5. (Optional) On the Incident Details page, to view the user actions that are iivailable 
to vou for the incident, click Additional Diagnostics. Each user action provides a 
wav for you to gather additional diagnostics for the incident or its problem. 

See Also: "Incident Flood Control" on page 8-3 



Creating a User-Reported Problem 



Sv stem -genera ted problems — critical errors generated internallv to the database — are 
automatically added to the Automatic Diagnostic Repositorv (ADR) and tracked in the 
Support Workbench. From the Support Workbench, vou can gather additional 
diagnostic data on these problems, upload diagnostic data to Oracle Support, and in 
some cases, resolve the problems, all with the easv-to-use workflow that is explained 
in "Investigating, Reporting, and Resolving a Problem" on page 8-9. 

There mav be a situation in which you want to manually add a problem that you 
noticed to the ADR so that vou can put that problem through that same workflow. An 
example of such a situation might be a global database performance problem that was 
not diagnosed by Automatic Diagnostic Database Monitor (ADDM). The Support 
Workbench includes a mechanism for vou to create and work with such a 
user-reported problem. 



To create a user-reported problem: 

1 . Access the Support Workbench home page. 

See "Viewing Problems with the Enterprise Manager Support Workbench" on 
page 8-16 for instructions. 

2. Under Related Links, chck Create User-Reported Problem. 

The Create User-Reported Problem page appears. 
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3. If vour problem matches one of the listed issue types, select the issue type, and 
then click Run Recommended Advisor to attempt to solve the problem with an 
Oracle ad\'isor. 



Managing Diagnostic Data 8-17 



Viewing the Alerl Log 



4. If the recommended advisor did not solve the problem, or if vou did not run an 
advisor, do one of the following: 

■ If your problem matches one of the hsted issue types, select the issue type, and 
then click Conlinue with Creation of Problem. 

■ If vour problem does not match one of the listed issue types, select the issue 
t\'pe None of the Above, enter a description, and then click Continue with 
Creation of Problem, 

The Problem Details page appears, 

5. Follow the instructions on the Problem Details page. 

See "Investigating, Reporting, and Resolving a Problem " on page 8-9 for more 
information. 

See Also: "About the Oracle Database Fault Diagnosabilitv 
Infrastructure" on page 8-1 for more information on problems and the 
ADR 



Viewing the Alert Log 



You can view the alert log with a text editor, with Enterprise Manager, or with the 
ADRCI utiUt;'. 

To view the alert log with Enterprise Manager: 

1. Access the Database Home page in Enterprise Manager. 

For Oracle Enterprise Manager Database Control, see Oracle Database 2 Day DBA 
for instructions. For Oracle Enterprise Manager Grid Control, go to the desired 
database target, 

2. Under Related Links, chck Alert Log Contents. 
The View Alert Log Contents page appears. 

3. Select the number of entries to view, and then click Go. 

To view the alert log with a text editor: 

1. Connect to the database withSQL'Plus or another querv tool, such as SQL 
Developer 

2. Querv the VSDIAG_INFO view as shown in "Viewing ADR Locations with the 
V$DlAG_INFO View" on page 8-8. 

3. To view the text-only alert log, without the XML tags, complete these steps: 

a. In the VSDIAG_INFO quer;' results, note the path that corresponds to the 
Diag Trace entr)', and change directory to that path. 

b. Open file alert_S/D.log with a text editor 

4. To view the XML-formatted alert log, complete these steps: 

a. In the V$DIAG_INFO query results, note the path that corresponds to the 
Di ag Al er t entn', and change directorv to that path. 

b. Open the file log.xml with a text editor. 

See Also: Oracle Database LlSilities for information about using the 
ADRCI utility to view a text version of the alert log (with XML tags 
stripped) and to run queries against the alert log 
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Finding Trace Files 



Trace files are stored in the Automatic Diagnostic Repository (ADR), in tlie trace 
directory under eacli ADR liome. To lielp vou locate individual trace files within this 
directory, you can use data dictionary yiews. For example, you can find the path to 
your current session's trace file or to the trace file for each Oriicle Database process. 

To find the trace file for your current session: 

■ Submit the following query: 

SELECT VALDE FROM VSDIAG_INFO WHERE HfflE = 'Default Trace File',- 

The full path to the trace file is returned. 

To find all trace files for the current instance: 

■ Submit the following query: 

SELECT VALUE FROM VSDIAG_INFO I'fflERE HflME = 'Diag Trace'; 

The path to the ADR trace directory for the current instance is returned. 

To determine the trace file for each Oracle Database process: 

■ Submit the following query: 

SELECT PID, PROGRAM, TRACEFILE FROM VSPROCESE; 

See Also: 

■ "Structure, Contents, and Location of the Automatic Diagnostic 
Repository " on page 8-6 

■ The ADRCI SHOW TRACEFILE command in Oracle Database 
Utilities 

Running Health Checks with Health Monitor 

This section describes the Health Monitor and includes instructions on how to use it. 
The follow^ing topics are coyered: 

About Health Monitor 

Ruruiing Health Checks Manually 

Viewing Checker Reports 

Health Monitor Views 

Health Check Parameters Reference 

About Health Monitor 

Beginning with Release 11^, Oracle Database includes a framew?ork called Health 
Monitor for running diagnostic checks on the database. 

About Health Monitor Checks 

Health Monitor checks (also known as checkers, health checks, or checks) examine 
various layers and components of the database. Health checks detect file corruptions, 
physical and logical block corruptions, undo and redo corruptions, data dictionary 
corruptions, and more. The health checks generate reports of their findings and, in 
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many cases, recommendations for resolving problems. Healtii checks can be run in 
two ways: 

■ Reactive — Tlie fault diagnosabilily infrastructure can run health checks 
automatically in response to a critical error 

■ Manual — As a DBA, vou can manually run health checks using either the DBMS_ 
HM PL/SQL package or the Enterprise Manager interface. You can run checkers on 
a regular basis if desired, or Oracle Support may ask you to run a checker while 
working with you on a service request. 

Health Monitor checks store findings, recommendations, and other information in the 
Automatic Diagnostic Repository (ADR). 

Health checks can run in two modes: 

■ DB-online mode means the check can be run while the database is open (that is, in 
OPEN mode or MOUNT mode). 

■ DB-offline mode means the check can be run when the instance is available but 
the database itself is closed (that is, in NOMOUNT mode). 

All the health checks can be run in DB-online mode. Only the Redo Integrity Check 
and the DB Structure Integrity Check can be used in DB-offline mode. 

See Also: "Automatic Diagnostic Repository' (ADR)" on page 8-4 



Types of Health Checks 

Health monitor runs the following checks: 

■ DB Structure Integrity Check — This check verifies the integrit}" of database files 
and reports failures if these files are inaccessible, corrupt or inconsistent. If the 
database is in mount or open mode, this check examines the log files and data files 
hsted in the control file. If the database is in NOMOUNT mode, only the control file is 
checked. 

■ Data Block Integrity Check — This check detects disk image block corruptions 
such as checksum failures, head/ tail mismatch, and logical inconsistencies within 
the block. Most corruptions can be repaired using Block Media Recovery, 
Corrupted block information is also captured in the V$DATaBASE_BLOCK_ 
CORRUPTION view. This check does not detect inter-block or inter-segment 
corruption, 

■ Redo Integrity Check — This check scans the contents of the redo log for 
accessibilit}" and corruption, as well as the archive logs, if available. The Redo 
lntegrit\' Check reports failures such as archive log or redo corruption. 

■ Undo Segment Integrity Check — This check finds logical undo corruptions. After 
locating an undo corruption, this check uses PMON and SMON to try to recover 
the corrupted transaction. If this recovery fails, then Health Monitor stores 
information about the corruption in V5C0RRUPT_XID_L I ST, Most undo 
corruptions can be resolved by forcing a comn\it, 

■ Transaction Integrity Check — This check is identical to the Undo Segment 
Integrity Check except that it checks only one specific transaction, 

■ Dictionary Integrity Check — This check examines the integrity of core dictionary 
objects, such as tab$ and colS, It performs the following operations: 

- Verifies the contents of dictionary entries for each dictionary object. 
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- Performs a cross-row level check, which verifies that logical constraints on 
rows in the dictionary are enforced, 

- Performs an object relationship check, which verifies that parent-child 
relationships between dictionary objects are enforced. 

The Dictionary Integrity Check operates on the following dictionary objects; 

tab$, cluS, fetS.uetS, segS, undoS, tsS, fileS, ob j $, in.d.$, icol$, col$, 
userS, conS, cdef $, ccol$, bootstraps, objauth$, ugroup$, tsq$, syn$, 

viewS, tYped_viewS, superobj $, seqS, lob$, coltype$, subcoltype$, 
ntab$, ref conS, opqtypeS, dependency$, acces s $, viewcon$, icoldepS, 
duals, sysauthS, objprivS, defroleS, and ecol$. 

Running Health Checks Manually 

Health Monitor provides two wavs to run health checks manually: 

■ By using the DBMS_HM PL /SQL package 

■ By using the Enterprise Manager interface, found on the Checkers subpage of the 
Advisor Central page 

Running Health Checks Using the DBMS_HM PL/SQL Package 

The DBMS_HM procedure for running a health check is called RUN_CHECK, To call RUH_ 
CHECK, supply the name of the check and a name for the run, as follows; 

BEGIN 

DBMS_HM.RUH_CHECK( 'Dictionary Integrity Check', 'my_run'); 
END; 

To obtain a list of health check names, run the following query; 

SELECT name FROM vShiii_check WHERE internal_check= 'H ' ; 

NAME 



DB Structure Integrity Check 
Data Block Integrity Check 
Redo Integrity Check 
Transaction Integrity Check 
Undo Segment Integrity Check 
Dictionary Integrity Check 

Most health checks accept input parameters. You can view parameter names and 
descriptions with the VSHM_CHECK_PARSM view. Some parameters are mandatory 
while others are optional. If optional parameters are omitted, defaults are used. The 
following query displays parameter information for all health checks; 

SELECT c.naine check_naine, p. name paraineter_naine, p. type, 

p.default_value, p. description 

FROM vShm_check_param p, vShm_check c 

WHERE p.check_id = c . id and c .internal_check = 'N' 

ORDER BY c.name; 

Input parameters are passed in the input_params argument as name/value pairs 
separated by semicolons (;). The following example illustrates how to pass the 
transaction ID as a parameter to the Transaction Integrity Check; 

BEGIN 

DBMS HM.RUH CHECK ( 
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checkjiame => 'Transaction Integrity Check', 

run_naine => 'my_run' , 

input_paraiiiE => ' TXN_ID=7 . 33 . 2 ' ) ; 
END; 

See Also: 

■ "Health Check Parameters Reference" on page 8-25 

■ Oracle Database PL/SQL Packages and Types Rejerencc for more 
examples of using DBMS_HM. 

Running Health Checks Using Enterprise Manager 

Enterprise Manager pro\'ides an interface for running Health Monitor checkers. 

To run a Health Monitor Checker using Enterprise Manager: 

1. On the Database Home page, in the Related Links section, click Advisor Central. 

2. Click Checkers to view the Checkers subpage. 

3. In the Checkers section, click the checker you want to run. 

4. Enter values for input parameters or, for optional parameters, leave them blank to 
accept the defaults. 

5. Click Run, confirm vour parameters, and click Run again. 



Viewing Checker Reports 



After a checker has run, vou can view a report of its execution. The report contains 
findings, recommendations, and other information. You can view reports using 
Enterprise Manager, the ADRCl utiUty, or the DBMS_HMPL/SQL package. The 
following table indicates the report formats available with each viewing method. 



Report Viewing Method Report Formats Available 

Enterprise Manager HTML 

DBMS_HM PL /SQL package HTML, XML, and text 

ADRCI utiliU' XML 

Results of checker runs (findings, recommendations, and other information) are stored 
in the ADR, but reports are not generated immediatelv. When vou request a report 
with the DBMS_HM PL/SQL package or with Enterprise Manager, if the report does not 
yet exist, it is first generated from the checker run data in the ADR, stored as a report 
file in XML format in the HM subdirectory of the ADR home for the current instance, 
and then displaved. If the report file alreadv exists, it is just displayed. When using the 
ADRCl utilit}', vou must first run a command to generate the report file if it does not 
exist, and then run another command to displav its contents. 

The preferred method to view checker reports is with Enterprise Manager, The 
following sections provide instructions for all methods: 

■ Viewing Reports Using Enterprise Manager 

■ Viewing Reports Using DBMS_HM 

■ Viewing Reports Using the ADRCI Utility 
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See Also: "Automatic Diagnostic Repository (ADR)" on page &4 

Viewing Reports Using Enterprise Manager 

YoLL can also view Health Monitor reports and findings for a given checker run using 
Enterprise Manager. 

To view run findings using Enterprise Manager 

1. Access the Database Home page. 

For Oracle Enterprise Manager Database Control, see Oracle Database 2 Day DBA 
for instructions. For Oracle Enterprise Manager Grid Control, go to the desired 
database target. 

2. In the Related Links section, click Advisor Central, 

3. Click Checkers to view the Checkers subpage. 

4. Click the run name for the checker run that vou want to view. 

The Run Detail page appears, showing the findings for that checker run. 

5. Click Runs to display the Runs subpage. 

Enterprise Manager displays more information about the checker run. 

6. Chck View Report to view the report for the checker run. 
The report is displayed in a new browser window. 

Viewing Reports Using DBMS_HM 

You can view Health Monitor checker reports with the DBMS_HM package function 
GET_RUH_REPORT. This function enables you to request HTML, XML, or text 
formatting. The default format is text, as shown in the following SQL*Plus example; 

SET LOHG 100000 
SET LOHGCHUNKSIZE 1000 
SET PAGES I ZE 1000 
SET LINES I ZE 512 

SELECT DBMS_HM.GET_RU[J_EEPORT( 'HH_RUH_1061' } FROM DUAL; 



DBMS HM.GET RUM REPORT (' HM RUH 1061' 



Run Hame 




HM RUH 1061 




Run Id 




1061 




Check Name 




Data Block Integrity Check 




Mode 




REftCTIVE 




Status 




CCMPLETED 




Start Time 




2007-05-12 22:11:02.032292 


-07:00 


End Time 




2007-05-12 22:11:20.835135 


-07:00 


Error ESicoiintered 









Source Incident Id 




7418 




Number of Incidents 


Created 








Input Paramters for the Run 
BLC_DF_NUM=1 
BLC_BL_NUM=64349 

Run Findings And Recommendations 
Finding 
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Finding Hame : Media Black Corruption 

Finding ID : 1055 

Type : FAILURE 

Status : OPEN 

Priority : HIGH 

Message : Block 64349 in datafile 1: 

' /ade/sfogel_emdb/oracle/dbs/t_dbl. £ ' is media cornipfc 
Message : Object BMRTESTl owned by SYS might be unavailable 

Finding 
Finding Hame 
Finding ID 
Type 
Status 
Priority 
Message 



Media Block Corruption 

1071 
FAILURE 
OPEN 
HIGH 

Block 64351 in datafile 1: 
' /ade/sfogel_emdb/oracle/dbs/t_dbl. f ' is media corrupt 
Message : Object BMRTEST2 owned by SYS might be unavailable 

See Also: Oracle Database PL/SQL Packages and Types Reference for 
details on the DBMS_HM package. 

Viewing Reports Using the ADRCi Utility 

YoiL can create and view Health Monitor checker reports using the ADRCI utility. 

To create and view a checker report using ADRCI 

1. Ensure that operating system enyironment variables (such as ORACLE_HOME) are 
set properly, and then enter the following comm.ind at the operating system 
command pron\pt: 

ADRCI 

The utility' starts and displays the following prompt 

adrci» 

Optionally, you can change the current ADR home. Use the SHOW HOMES 
command to list all ADR homes, and the SET HOMEPATH command to change the 
current ADR home. See Oracle Database Utilities for more information. 

2. Enter the following command: 

show hni_run 

This command lists all the checker runs (stored in VSHM_RUN) registered in the 
ADR repository. 

3. Locate the checker run for v^fhich you want to create a report and note the checker 
run name. The REPORT_FILE field contains a filename if a report already exists 
for this checker run. Othenvise, generate the report with the following command: 

create report hm_run run_nsme 

4. To yiew the report, enter the following command: 

show report hm_run run_narae 



See Also: "Automatic Diagnostic Repository (ADR)" on page 8-4 
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Health Monitor Views 



Instead of requesting a checker report, you can view the resuhs of a specific checker 
run bv directly quer;'ing the ADR data from which reports are created. Ttiis data is 
available through the views VSHM_RUM, VSHM_FINriING, and VSHM_ 

RECOMMENDATION. 

The follow^ing example queries the VSHM_RUN view to determine a history of checker 
runs: 

SEIECT 3ruii_id, name, checkjiame, ruii_inode, src_incident FROM v3hm_run; 



RUM ID NAME 



CHECK NAME 



RUM MODE SRC IHCIDENT 



1 hm_r™_i 
101 hm_r™_ioi 

121 TXNCHK 
181 HMR_tal)S 



DB Structure Integrity Check 
Transaction Integrity Check 
Transaction Integrity Check 
Dictionary Integrity Check 



REACTIVE 





REACTIVE 


6073 


MSffllAL 





MANUAL 






981 Proct_tE$ Dictionary Integrity Check 

1041 eM_RUM_1041 DB Structure Integrity Check 
1061 HM_RHM_1061 Data Block Integrity Check 



MAMUAL 





REACTIVE 





REACTIVE 


7418 



The next example queries the VSHM_FINDING view to obtain finding details for the 
reactive data block check with RUN_ID 1061: 

SEIECT type, description FROM v$hni_f inding WHERE run_id = 1061; 



TYPE 



DESCRIPTION 



FAILURE Block 54349 in datafile 1: 7ade/sfogel_e 

radb/oracle/dbs/t_dbl. f ' is media corrupt 

FAILURE Block 54351 in datafile 1: 7ade/sf ogel_e 

radl;/oracle/dbs/t_dl]l. f ' is media corrupt 

See Also: 

■ "Types of Health Checks" on page 8-20 

■ Oracle Database Reference for more information on the VSHM_* 
views 



Health Check Parameters Reference 



The following tables describe the parameters for those health checks that require them. 
Parameters with a default value of (none) are mandatory. 



Table 8-5 Parameters for Data Block Integrity Check 



Parameter Name Type 


DefauFt Value 


Description 


BLC_DF_HHM Number 
BLC_BL_HDM Number 


(none) 
(none) 


Block data file number 
Data block number 


Table 8-6 Parameters for Redo Integrity ChetA 


Parameter Name Type 


Default Value 


Description 









SCN_TEXT Text 


SCN of the latest good redo [if known) 
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Table 8-7 Parameters for Undo Segment Integrity Check 



Parameter Name Type 

USN NUMBER Text 



Default Value 



Description 



Undo segment number 



Table 8-8 Parameters for Transaction Integrity Check 



Parameter Name Type 



Default Value 



Description 



TXN ID 



Text 



(none) 



Transaiition ID 



Table 8-9 Parameters for Dictionary Integrity Check 



Parameter Name Type 



Default Value 



Description 



CHECK MASK 



Text 



TABLE HAME 



Text 



ALL Possible values are: 

■ COLUMH_CHECKS — Run column 
checks only Verify column-level 

constraints in the core tables. 

■ ROW_CHECKS — Run row checks 
only Verif}' row-level constraints 
in the core tables. 

■ REFEREHTIAL_CHECKS— Run 
referential checks only. Verify 
referential constraints in the core 

tables, 

■ ALL — Run all checks. 

ALL_CORE_TABLES Name of a single core table to check. If 
omitted, all core tables are checked. 



Repairing SQL Failures witli tlie SQL Repair Advisor 



In the rare case that a SQL statement fails with a critical error, you can run the SQL 
Repair Advisor to trv to repair the failed statement. 

This section covers the foUowing topics: 

■ About the SQL Repair Advisor 

■ Running the SQL Repair Advisor 

■ Viewing, Disabling, or Removing a SQL Patch 



About the SQL Repair Advisor 



You run the SQL Repair Advisor after a SQL statement fails with a critical error. The 
advisor analvzes the statement and in many cases recommends a patch to repair the 
statement If you implement the recommendation, the applied SQL patch circumvents 
the failure bv causing the query optimizer to choose an alternate execution plan for 
future executions. 



Running the SQL Repair Advisor 



You run the SQL Repair Advisor from the Problem Details page of the Support 
Workbench. The instructions in this section assume that vou were already notified of a 
critical error caused by your SQL statement and that vou followed the workflow 
described in "Investigating, Reporting, and Resolving a Problem" on page 8-9, 
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To run the SQL Repair Advisor: 

1. Access the Problem Details page for the problem that pertains to the failed SQL 
statement. 

See "Viewing Problems with the Enterprise Manager Support Workbench" on 
page 8-16 for instructions, 

2. In the Investigate and Resolve section, under the Seli Service tab, under the 
Resolve heading, click SQL Repair Advisor. 



Database Instance: database > Support Workbench > Logged in A^ SYSTEM 
Problem Details: ORA 600 [13011] 




P^e Refreshed March 20, 2007 9:05:i5PM POT ( Rpfre^ll 




Summary 


InvBstfqate and Resolve 




[ Go 10 MeialmK ) ( Quick Package ] 
1 Self Service | Oracle SuDDort 

A&ie&& Damage 


SR# __ ( Efllt ) 
Bug* __ [ Eon ] 
Active Yes 
Packaged No 
Number of Incidents 1 
LasI Incldenl 


Run Checkers 

Database Instance Health 


Time^taiTiD March ZO. ZD07 8;18;05 PM PDT 
Incident Source System Cjenerated 

Impact 
Checkers Run 
Checker Findings 




Alert Loo 

Related Problems Ao'DiG TddqIoov 
Di jono^bc Dumo? for Last InndEnt 
Gd tn Matallnk and Research 




RAuive 




501 Reoalr Advisor 












1 


1 Incident* | ActivitvLoa 





The SQL Repair Advisor page appears. 

3. Enter an optional task name, set an optional time limit for the advisor task, and 
adjust settings to schedule the advisor to run either immediatelv or at a future 
date and time. 

4. Click Submit. 

A "processing" page appears. After a short delay, the SQL Repair Results page 
appears. 



SQ L Repar Results: SQL_DlftG_117^506262358 



status caM>LETED 
35LID 9mTmyytcb4dl4 

Tme Limit (second?) IBOO 



age RBffeshed Mar21,?007 12:4550 PM PDT ( F^aresn ] 

Started r^ar21, 2D07 1?:45:28 PMPDT 
completed r*larzi, ZDOT 1Z:45:46 pr*1PDT 

Dunning Time (second?) 18 



Recommendations 

I fvigw J 

SeIecL BQL TElt 



delete FiDmttI wheie tl a = 'a' android li (setctmi((iDwdll.Qratl2TJitieietl fl=:t2 eandtl 



' Parsing sEhpmd 5JL ID 5QI Patcli 

9m7mvvtcb4dl4 j' 



A check mark in the SQL Patch column indicates that a recommendation is 
present. The absence of a check mark in this column means that the SQL Repair 
Advisor was unable to devise a patch for the SQL statement. 

5. If a recommendation is present, click View to view the recommendation. 

The Repair Recommendations page appears, showing the recommended patch for 
the statement. 

6. Click Implement. 
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The SQL Repair Results page returns, showing a confirmation message. 

7. (Optional) Chck Verify using SQL Worksheet to run the statement in the SQL 
woricsheet and verif\' that tlie patcli successfully repaired the statement. 

Viewing, Disabling, or Removing a SQL Patch 

After vou apply a SQL patch with the SQL Repair Advisor, you may want to view it to 
confirm its presence, disable it, or remove it. One reason to remove a patch is if vou 
install a later release of Oracle Database that fixes the bug that caused the failure in the 
patched SQL statement. 

To view, disable, or remove a SQL patch: 

1. Access the Database Home page in Enterprise Manager. 

For Oracle Enterprise Manager Database Control, see Oracle Database 2 Day DBA 
for instructions. For Oracle Enterprise Manager Grid Control, go to the desired 
database target. 

2. At the top of the page, click Server to display the Server page. 

3. In the Query Optimizer section, chck SQL Plan Control. 

The SQL Plan Control page appears. See the online help for information about this 
page. 

4. At the top of the page, click SQL Patch to display the SQL Patch subpage. 
The SQL Patch subpage displays all SQL patches in the database. 

5. Locate the desired patch by examining the associated SQL text. 
Click the SQL text to view the complete text of the statement. 

6. To disable the patch, select it, and then click Disable. 

A confirmation message appears, and the patch status changes to DI SABLED. You 
can later reenable the patch by selecting it and clicking Enable. 

7. To remove the patch, select it, and then click Drop. 
A confirmation message appears. 

See Also: "About the SQL Repair Advisor" on page 8-26 

Repairing Data Corruptions with the Data Recovery Advisor 

You use the Data Recoverv Advisor to repair data block corruptions, undo 
corruptions, data dictionarv corruptions, and more. The Data Recoverv Advisor 
integrates with the Enterprise Manager Support Workbench (Support Workbench), 
with the Health Monitor, and with the RMAN utilit\' to display data corruption 
problems, assess the extent of each problem (critical, high priority, low priorit}'), 
describe the impact of a problem, recommend repair options, conduct a feasibility 
check of the customer-chosen option, and automate the repair process. 

Orack Database 2 Day DBA provides details on how to use the Data Recovery Advisor 
This section describes the various wavs to access the advisor from the Support 
Workbench. 

The Data Recovery Advisor is automaticallv recommended by and accessible from the 
Support Workbench when vou are viewing: 
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■ Problem details for a problem that is related to a data corruption or other data 
failure. 

■ Health checker findings that are related to a data corruption or other data failure. 

The Data Recovery Advisor is also available from the Advisor Central page. A link to 
this page can be found in the Related Links section of the Database Home page and of 
the Performance page. 



Note: The Data Recoverv Advisor is available only when vou are 
connected as SYSDBA. 



You access the Data Recovery Advisor from the Support Workbench in the following 
ways: 

■ From the Problem Details page 



Database Instance: database > GLipport Workbencb > 

Problem Details: ORA 1578 



Logged In As SV5TEM 



Summary 



SR# 


-- 


(EclO 


Bug# 


-- 


( EcilT 3 


Active 


No 




Packaged 


No 




NuiTiber oF Incidents 


4 




Fir^t Inciijenl: 


mas 12, 2007 3:24:39 PMPDT 


La ft Incident 






Time&tarfiD 


M^V 12. 2007 3:24:54 PMPDT 


Inciijenl: Source 


System Generated 


impact 






checkers Run 







checker Findings 








Page Refreshed May 12,2007 4:18:54PMPDT ( Refresh ] 



Investi gate and .Re?D|ve_ 



y Gq ^Q MeialmK J ( Quick Package ^ 
/Ice Oracle Supporl: 



sess Damage 

Cheiilter Findlnci^ 

Run Checkers 

Database Instancs Health 



Piaijnoie 



Alert Loi] 

Related Problems AcTo^^ TddoIdqv. 
DiaijnD^bic Duitid^ For La^b Incjdenb 
Go to ^J]gtalln^ and Research 



Data Recovery Adviror 



flcbvltv Loo 



Click the Data Recovery Advisor link in the Investigate and Resolve section. 

See "Viewing Problems with the Enterprise Mani^ger Support Workbench" on 
page 8-16 for instructions on how to access this page. 

From the Checker Findings subpage of the Support Workbench home page 
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Sup port Workbencti 



i Refre^hied May 12, ZOOT 4;Z5;15 PN PDT ( Refreill ] 



Problems Hi Checker Findings (15) Packages 10) 



Search) 

Description 



DaiTrage Tfanslafiori 



Open -.^\\ ill 



1a|rc7) 



Data Corruption 



Select findings and dick on me Launch Recovery Advisor button to repair those findings, 


L Launch Recovery Advisor ) 1 


Select ; 


II 1 Selech None 1 Expand All 1 Collaose All 








1 


Select 


tnoricy luaniage itan^iaDon 








Y All Findings 








D 


5QL dictionary health check; 
t^t.onlinej 41 on object TSj failed 


Critical 


Jamaged rowid is AAAAAGAAEAAAAGwAAA - 
description; Tablespace TEMP \s referenced 




Cpen 


■daj 12, 2007 3:31:00 PM 


D 


[►Datafile 1 ; 

7ade/^f ogel_emdb/ciracleydb sjf. _db 1 . f ' 
contairi? one or more corrupt blocks 


High 


Some objects in tablespace SYSTEM migbt be 
unavailable 


6233 


3pen 


VlaiilZ, 2007 3:25; 15 PM 


D 


I^Undo segment 9 15 corrupted 


High 




6237 


5pen 


^ay 12, 2007 3:28:21 PM 
PDT 


□ 


|>-Undo segment 10 is corrupted High 




6239 


open 


^a¥ 12, 2007 3:29:20 PM 
=DT 



Select one or more data corruption findings and then click Launch Recovery 
Advisor, 

See "Viewing Problems with the Enterprise Manager Support Workbench" on 
page 8-16 for instructions on how to access the Support Workbench home page. 

See Also: Oracle Database 2 Daij DBA for instructions for running the 
Data Recovery Advisor 

Creating, Editing, and Uploading Custom Incident Packages 

This section provides background information on incident packages, and explains how 
to create, modifv, and upload customized packages with the Enterprise Manager 
Support Workbench (Support Workbench) custom packaging process. The following 
topics are covered: 

■ About Incident Packages 

■ Packaging and Uploading Problems with Custom Packaging 

■ Viewing and Modifying Incident Packages 

■ Setting Incident Packaging Preferences 

See Also: "About the Oracle Database Fault Diagnosability 
Infrastructure" on page 8-1 

About Incident Packages 

For the customized approach to uploading diagnostic data to Oracle Support, vou first 
collect the data into an intermediate logical structure called an incident package 
(package). A package is a collection of metadata that is stored in the Automatic 
Diagnostic Repository (ADR) and that points to diagnostic data files and other files 
both in and out of the ADR. When you create a package, vou select one or more 
problems to add to the package. The Support Workbench then automaticallv adds to 
the package the problem information, incident information, and diagnostic data (such 
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as trace files and dumps) associated witli the selected problems. Because a problem 
can have manv incidents (many occurrences of the same problem), bv default onlv the 
first three and last three incidents for each problem are added to the package, 
excluding anv incidents that are over 90 davs old. You can change these default 
numbers on the Incident Packaging Configuration page of the Support Workbench. 

After the package is created, you can add any type of external file to the package, 
remove selected files from the package, or edit selected files in the package to remove 
sensitive data. As you add and remove package contents, onlv the package metadata is 
modified. 

When vou are readv to upload the diagnostic data to Oracle Support, you first create a 
zip file that contains all the files referenced bv the package metadata. You then upload 
the zip file through Oracle Configuration Manager, 

Note: If you do not have Oracle Configuration Manager installed and 
properly configured, vou must upload the zip file manually through 

OracleMt'irtL/Vi/c. 

For more information about Oracle Configuration Manager, see Oracle 
Configuration Manager Installation and Administration Guide. 



More information about packages is presented in the following sections: 

■ About Correlated Diagnostic Data in Incident Packages 

■ About Quick Packaging and Custom Packaging 

See Also: 

■ "Packaging and Uploading Problems with Custom Packaging" on 
page 8-33 

■ "Viewing and Modif\'ing Incident Packages" on page 8-36 

About Correlated Diagnostic Data in Incident Pacltages 

To improve the diagnosabilit\' of a problem, it is sometimes necessar}" to examine not 
onlv diagnostic data that is directh' related to the problem, but also diagnostic data 
that is correlated with the directlv related data. Diagnostic data can be correlated by 
time, bv process ID, or by other criteria. For example, when examining an incident, it 
mav be helpful to also examine an incident that occurred five minutes after the 
original incident, Similarlv, while it is clear that the diagnostic data for an incident 
should include the trace file for the Oracle Database process that was running when 
the incident occurred, it might be helpful to also include trace files for other processes 
that are related to the original process. 

Thus, when problems and their associated incidents are added to a package, any 
correlated incidents are added at the same time, with their associated trace files. 

During the process of creating the physical file for a package, the Support Workbench 
calls upon the Incident Packaging Service to finalize the package. Finalizing means 
adding to the package anv additional trace files that are correlated by time to incidents 
in the package, and adding other diagnostic information such as the alert log, health 
checker reports, SQL test cases, configuration information, and so on. This means that 
the number of files in the zip file mav be greater than the number of files that the 
Support Workbench had previously displayed as the package contents. 
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The Incident Packaging Sen'ice follows a set of rules to determine the trace files in the 
ADR that are correlated to existing package data. You can niodifv some of those rules 
in the Incident Packaging Configuration page in Enterprise Manager, 

Because both initial package data and added correlated data mav contain sensitive 
information, it is important to have an opportunit}" to remove or edit files that contain 
this information before uploading to Oracle Support. For this reason, the Support 
Workbench enables you to run a command that finalizes the package as a separate 
operation. After manually finalizing a package, vou can examine the package contents, 
remove or edit files, and then generate and upload a zip file. 

Note: Finalizing a package does not mean closing it to further 
modifications. You can continue to add diagnostic data to a finalized 
package. You can also finalize the same package multiple times. Each 
time that you finalize, any new correlated data is added. 



See Also: "Setting Incident Packaging Preferences" on page 8-42 

About Quick Packaging and Custom Pacltaging 

The Enterprise Manager Support Workbench provides two methods for creating and 
uploading an incident package: the quick packaging method and the custom 
packaging method. 

Quick Packaging — This is the more automated method with a minimum of steps, 
organized in a guided workflow (a wizard). You select a single problem, provide a 
package name and description, and then schedule upload of the package contents, 
either immediately or at a specified date and time. The Support Workbench 
automaticallv places diagnostic data related to the problem into the package, finalizes 
the package, creates the zip file, and then uploads the file. With this method, vou do 
not have the opportunit\' to add, edit, or remove package files or add other diagnostic 
data such as SQL test cases. However, it is the simplest and quickest wav to get 
first-failure diagnostic data to Oracle Support. 

Note that when quick packaging is complete, the package that was created bv the 
wizard remains. You can tlien modif\' the package with custom packaging operations 
at a later time and manually reupload. 

Custom Packaging — This is the more manual method, with more steps. It is intended 
for expert Support Workbench users who want more control over the packaging 
process. With custom packaging, you can create a new package with one or more 
problems, or vou can add one or more problems to an existing package. You can then 
perform a variety of operations on the new or updated package, including: 

Adding or removing problems or incidents 

Adding, editing, or removing trace files in the package 

Adding or removing external files of any type 

Adding other diagnostic data such as SQL test cases 

Manually finalizing the package and then viewing package contents to determine 
if you must edit or remove sensitive data or remove files to reduce package size. 

You might conduct these operations over a number of days, before deciding that vou 
have enough diagnostic information to send to Oracle Support, 
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With custom packaging, vou create the zip file and request upload to Oracle Support 
as two separate steps. Each of these steps can be performed immediately or scheduled 
for a future date and time. 

See Also: "Task 5 - Package and Upload Diagnostic Data to Oracle 
Support " on page 8-13 for instructions for the Quick Packaging 
method 

Packaging and Uploading Probiems witfi Custom Packaging 

This section walks vou through an advanced workflow to view and package one or 
more problems for upload to Oracle Support. This workflow uses the custom 
packaging facilitv of the Support Workbench, which enables you to add, edit, and 
remove files from the incident package (package) before uploading. 

To package and upload problems with custom packaging: 

1 . Access the Support Workbench home page. 

See "Viewing Problems with the Enterprise Manager Support Workbench" on 
page 8-16 for instructions, 

2. (Optional) For each problem that vou want to include in the package, indicate the 
service request number (SR#) associated with the problem, if anv. To do so, 
complete the following steps for each problem: 

a. In the Problems subpage at the bottom of the Support Workbench home page, 
select the problem, and then click Vieiv, 

Note: If vou do not see the desired problem in the list of problems, 
or if there are too manv problems to scroll through, select a time 
period from the View list and click Go. You can then select the desired 
problem and click View. 

The Problem Details page appears, 

b. Next to the SR# label, click Edit, enter a service request number, and then click 
OK. 

The service request number is displaved on the Problem Details page, 

c. Return to the Support Workbench home page by clicking Support Workbench 
in the locator links at the top of the page. 



Database Instance: database > Support Workbench > 
Probl em details (4) 



3. On the Support Workbench home page, select the problems that you want to 
package, and then click Package, 

The Select Packaging Mode page appears. 



Note: The packaging process may automatically select additional 
correlated problems to add to the package. An example of a correlated 
problem is one that occurs within a few minutes of the selected 
problem. See 'About Correlated Diagnostic Data in Incident Packages" 
on page 8-31 for more information. 
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4. Select the Custom packaging option, and tlien click Conlinue. 
The Select Package page appears. 



Figure 6-5 Select Package Page 
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5. Do one of the foUowing: 

■ To create a new package, select the Create newr package option, enter a 
package name and description, and then click OK. 

■ To add the selected problems to an existing package, select the Select from 
existing packages option, select the package to update, and then click OK. 

The Customize Package page appears. It displays the problems and incidents that 
are contained in the package, plus a selection of packaging tasks to choose from. 
You run these tasks against the new package or the updated existing package. 



Figure 8-6 Customize Padcage Page 



Database Instance: database > Support Workbench 
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Logged in As SYSTEM 



Package(Pkg_0S2207l6]722) has been created successfully. 
Customize Pacl<age; Pl<g_052207161722 



Page Refreshed MayZ2,Z007 4;17:45PM PDT ( Refresh ) 
The package can be customized to edit its contents, to generate and include additional diagnostic data or to scrub user data. Once the package is ready it can be sent to Oracle Support. 
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6. (Optional) In the Packaging Tasks section, click links to perform one or more 
packaging tasks. Or, use other controls on the Customize Package page and its 
subpages to manipulate the package. Return to the Customize Package page when 
vou are finished. 
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See "Viewing and Modifving Incident Packages" on page 8-36 for instructions for 
some of the most common packaging tasks, 

7. In the Packaging Tasks section of the Customize Ptickage page, under the heading 
Send to Oracle Support, click Finish Contents Preparation to finalize the package, 

A list (or partial list) of files included in the package is displayed. (This mav take a 
while.) The list includes files that were detern\ined to contain correlated diagnostic 
information and added by the finalization process, 

See "About Correlated Diagnostic Data in Incident Packages" on page 8-31 for a 
definition of package finalization, 

8. Chck the Files link to view all the files in the package. Examine the list to see if 
there are anv files that might contain sensitive data that vou do not want to 
expose. If vou find such files, exclude (remove) or edit them. 

See "Editing Incident Package Files (Copying Out and In)" on page 8-37 and 
"Removing Incident Package Files" on page 8-41 for instructions for editing and 
removing files. 

To view the contents of a file, click the eyeglasses icon in the rightmost column in 
the table of files. Enter host credentials, if prompted. 

Note: Trace files are generally for Oracle internal use only, 

9. Click Generate Upload File, 

The Generate Upload File page appears, 

10. Select the Full or Incremental option to generate a full package zip file or an 
incremental package zip file. 

For a full package zip file, all the contents of the package (original contents and all 
correlated data) are always added to the zip file. 

For an incremental package zip file, only the diagnostic information that is new or 
modified since the last time that vou created a zip file for the same package is 
added to the zip file. For example, if trace information was appended to a trace file 
since that file was last included in the generated physical file for a package, the 
trace file is added to the incremental package zip file. Conversely, if no changes 
were made to a trace file since it was last uploaded for a package, that trace file is 
not included in the incremental package zip file. 

Note: The Incremental option is dimmed (unavaUable) ii an upload 
file was never created for the package. 



1 1 . Schedule file creation either immediately or at a future date and time (select 
Immediately or Later), and then click Submit, 

File creation can use significant system resources, so it mav be advisable to 
schedule it for a period of low system usage, 

A Processing page appears, and creation of the zip file proceeds. A confirmation 
page appears when processing is complete. 

Note: The package is automatically finalized when the zip fUe is 
created. 
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12. Click OK. 

The C iistomize Package page returns. 

13. Click Send to Oracle. 

The View /Send Upload Files page appears. 

14. Select the zip files to upload, and then click Send to Oracle. 

The Send to Oracle page appears. The selected zip files are listed in a table. 

15. Fill in the requested OracleAicfaLiiik information. Next to Create new Service 
Request (SR), select Yes or No. If vou select Yes, a draft ser\'ice request will be 
created for vou. You must later log in to OtacieAicliiLiiik and fill in the service 
request details. If you select No, enter an existing ser\'ice request number 

16. Schedule the upload to take place immediately or at a future date and time, and 
then click Submit. 

A Processing page appears. If the upload is completed successfully, a confirmation 
page appears. If the upload could not complete, an error page appears. The error 
page niav include a message that requests that you upload the zip file to Oracle 
manually. If so, contact your Oracle Support representative for instructions, 

17. Click OK, 

The View /Send Upload Files page returns. Under the Time Sent column, check 
the status of the files that vou attempted to upload. 

Note: The Support Workbench uses Oracle Configuration Manager to 
upload the physical files. If Oracle Configuration Manager is not installed 
or properly configured, the upload may fail. In this case, a message is 
displayed with a path to the package zip file and a request that you 
upload the file to Oracle Support manuaUy, You can upload m.anually 
with OracieMefaLink. 

For more information about Oracle Configuration Manager, see Oracle 
Configitrafion Manager Installation and Administration Guide. 



See Also: 

■ "About Incidents and Problems" on page 8-3 

■ "About Incident Packages" on page 8-30 

■ "About Quick Packaging and Custom Packaging" on page 8-32 



Viewing and Modifying Incident Packages 



After creating an incident package with the custom packaging method, you can view 
or modify the contents of the package before uploading the package to Oracle Support, 
In addition, after using the quick packaging method to package and upload diagnostic 
data, vou can view or modify the contents of the package that the Support Workbench 
created, and then reupload the package. To modify a package, you choose from among 
a selection of packaging tasks, most of which are available from the Customize Package 
page. 

This section provides instructions for some of the most common packaging tasks. It 
includes the following topics: 

■ Editing Incident Package Files (Copying Out and In) 
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■ Adding an External File to an Incident Package 

■ Removing Incident Package Files 

■ Viewing and Updating the Incident Package Activity Log 

Also included are the following topics, which explains how^ to view package details 
and how to access the Customize Package page for a particular package: 

■ Viewing Package Details 

■ Accessing the Customize Package Page 

See Also: 

■ "About Incident Packages" on page 8-30 

■ "Packaging and Uploading Problems with Custom Packaging" on 
page 8-33 

Viewing Pacltage Details 

The Package Details page contains information about the incidents, trace files, and 
other files in a package, and enables you to vievi' and add to the package activity' log. 

To view package details: 

1 . Access the Support Workbench home page. 

See "Viewing Problems with the Enterprise Manager Support Workbench" on 
page 8-16 for instructions, 

2. Click the Packages link to view? the Packages subpage. 

A list of packages that are currentlv in the Automatic Diagnostic Repository 
(ADR) is displayed. 

3. (Optional) To reduce the number of packages displayed, enter text into the Search 
field above the list, and then click Go, 

All packages that contain the search text anywhere in the package name are 
displayed. To view the full list of packages, click the Packages link again, 

4. Under the Package Name column, click the link for the desired package. 
The Package Details page appears. 

Accessing tlie Customize Pacltage Page 

The Customize Package page is used to perform various packaging tasks, such as 
adding and removing problems; adding, removing, and scrubbing (editing) package 
files; and generating and uploading the package zip file. 

To access the Customize Package page: 

1. Access the Package Details page for the desired package, as described in "Viewing 
Package Details" on page 8-37, 

2. Chck Customize Package, 

The C ustomize Package page appears. 

Editing Incident Package Files (Copying Out and in) 

The Support Workbench enables vou to edit one or more files in an incident package. 
You may want to do this to delete or overwrite sensitive data in the files. To edit 
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package files, vou must first copy the files out of the package into a designated 
directory, edit the files with a text editor or other utility, and then copy the files back 
into the package, overwriting the original package files. 

The following procedure assumes that the package is already created and contains 
diagnostic data. 

To edit incident package files: 

1. Access the Customize Package page for the desired incident package. 

See "Accessing the Customize Package Page" on page 8-37 for instructions. 

2. In the Packaging Tasks section, under the Scrub User Data heading, click Copy out 
Files to Edit contents. 

The Copy Out Files page appears. It displays the name of the host to which vou 
can copv files. 



Figure 6-7 Copy Out Files Page 
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3. Do one of the following to specify a destination directorv for the files: 

■ Enter a director}' path in the Destination Folder field. 

■ Click the flashlight icon next to the Destination Folder field, and then 
complete the following steps: 

- If prompted for host credentials, enter credentials for the host to w^hich 
you want to copv out the files, and then click OK. (Select Save as 
Preferred Credential to avoid the prompt for credentials next time.) 

- In the Browse and Select File or Directory window, click directory hnks to 
move down the directorv hierarchy, and click directorv names next to the 
Path label to move up the directory hierarchy, until you see the desired 
destination directorv. 
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To reduce the number of directories displayed in the hst, enter search text 
in the Search field and click Go, All directories that have the search text 
anywhere in the directory' name are displayed, 

- Select the desired destination directory, and then click Select, 

The Brovi'se and Select File or Director}' window closes, and the path to 
the selected directory appears in the Destination Folder field of the Copy 
Out FUes page, 

4. Under Files to Copy Out, select the desired files, and then click OK, 



Note: If you do not see the desired files, they may be on another 
page. Click the Next link to view the next page. Continue clicking 
Nexl, or select from the list of file numbers (to the left of the Next link) 
until you see the desired files. You can then select the files and click 
OK, 



The Customize Package page returns, displaying a confirmation message that lists 
the files that were copied out, 

5. Using a text editor or other utility, edit the files, 

6. On the Customize Package page, in the Packaging Tasks section, under the Scrub 
User Data heading, click Copy in Files to Replace Contents, 

The Copv In Files page appears. It displays the files that vou copied out, 

7. Select the files to copy in, and then click OK, 

The files are copied into the package, overwriting the existing files. The Customize 
Package page returns, displaying a confirmation message that hsts the files that 
were copied in. 

Adding an External File to an Incident Pacltage 

You can add any tj'pe of external file to an incident package. 

To add an external file to an incident package: 

1. Access the Customize Package page for the desired incident package. 
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See "Accessing the Customize Package Page" on page 8-37 for instructions. 
2. Click the Files link to view the Files subpage. 



Figure 8-8 Files Subpage of Customize lockage f^ge 
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From tliis page, you can add and remove files to and from the package. 

Note: The View list appears only for packages for which vou already 
created a physical file. It enables vou to view either incremental 
package contents or the full package contents. The default selection is 
incremental package contents. This default selection displays only 
those package files that were created or modified since the last time 
that a physical file was generated for the package. 

3. Click Add external files. 

The Add External File page appears. It displays the host name from w^hich you 
may select a file. 

4. Do one of the following to specify a file to add: 

■ Enter the full path to the file in the File Name field. 

■ Click the flashlight icon next to the File Name field, and then complete the 
following steps: 

— If prompted for host credentials, enter credentials for the host on which 
the external file resides, and then click OK. (Select Save as Preferred 
Credential to avoid the prompt for credentials next time.) 

— In the Browse and Select File or Directory window, click directory links to 
move down the directory hierarchy, and click directory names next to the 
Path label to move up the directory hierarchy, until you see the desired 
file. 
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To reduce the number of files or directories displayed in the list, enter 
search text in the Search field and click Go, All files or directories that 
have the search text anywhere in the file name or directory name are dis- 
played, 

- In the Select column, click to select Ihe desired file, and then click Select, 

The Browse and Select window closes, and the path to the selected file 
appears in the File Name field of the Add External File page, 

5. Click OK, 

The C ustomize Package page returns, displaying the Files subpage. The selected 
file is now shown in the list of files. 

Removing Incident Package Fiies 

You can remove one or more files of any tvpe from the incident package. 

To remove incident package files: 

1 . Access the Customize Package page for the desired incident package. 

See "Accessing the Customize Package Page" on page 8-37 for instructions, 

2. Click the Files link to view the Files subpage, 

A list of files in the package is displayed. 

If vou have not yet generated a physical file for this package, all package files are 
displayed in the list. If you have already generated a physical file, a View list 
appears above the files list. It enables you to choose between viewing only 
incremental package contents or the full package contents. The default selection is 
incremental package contents. This default selection displays onlv those package 
files that were created or modified since the last time that a physical file was 
generated for the package. Select Full package contents from the View list to view 
all package files. 

3. Select the files to remove, and then click Exclude. 
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Note: If you do not see the desired fUes, they may be on another 
page. Click the Next Uni; to view the next page. Continue cUcJcing 
Next, or select from the list of file numbers (to the left of the Next link) 
until you see the desired files. You can then select the files and click 
Remove. 



Viewing and Updating the Incident Package Activity Log 

The Support Workbench maintains an activit}' log for each incident package. Most 
activities that vou perform on a package, such as adding or removing files or creating 
a package zip file, are recorded in the log. You can also add your own notes to the log. 
This is especiallv useful if more than one database administrator is working with 
packages. 

To view and update the incident paclcage activity log: 

1 . Access the Package Details page for the desired incident package. 

See "Accessing the Customize Package Page" on page 8-37 for instructions. 

2. Click the Activity Log link to view the Activity Log subpage. 
The activity log is displayed. 

3. To add vour own note to the activit\' log, enter text into the Note field, and then 
click Add Note. 



Your note is timestamped and appended to the list. 



Setting Incident Packaging Preferences 



This section provides instructions for setting incident packaging preferences. 
Examples of incident packaging preferences include the number of days to retain 
incident information, and the number of leading and trailing incidents to include in a 
package for each problem. (Bv default, if a problem has many incidents, only the first 
three and last three incidents are packaged.) You can change these and other incident 
packaging preferences with Enterprise Manager or with the ADRCl u.tilit\'. 

To set incident pacltaging preferences with Enterprise lUlanager: 

1. Access the Support Workbench home page. 

See "Viewing Problems with the Enterprise Manager Support Workbench" on 
page 8-16 for instructions. 

2. In the Related Links section at the bottom of the page, click Incident Packaging 
Configuration. 

The View Incident Packaging Configuration page appears. Click Help to view 
descriptions of the settings on this page. 

3. ChckEdit. 

The Edit Incident Packaging Configuration page appears. 

4. Edit settings, and then chck OK to apply changes. 
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See Also: 

■ "About Incident Packages" on page 8-30 

■ "About Incidents and Problems" on page 8-3 

■ "Tasks —Package and Upload Diagnostic Data to Oracle Support" 
on page 8-13 

■ Oracle Database Utilifks for information on ADRCl 
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This part describes database structure in terms of its storage components and how to 
create and manage tliose components. It contains the following chapters: 

Chapter 9, "Managing Control Files" 

Chapter 10, "Managing the Redo Log" 

Chapter 11, 'Managing Archived Redo Logs" 

Chapter 12, "Managing Tablespaces" 

Chapter 13, "Managing Datafiles and Tempfiles ' 

Chapter 14, "Managing Undo" 

Chapter 15, "Using Oracle-Managed Files" 



9 



Managing Control Files 



In this chapter: 

What Is a Control File? 

Guidelines for Control Files 

Creating Control Files 

Troubleshooting After Creating Control Files 

Backing Up Control Files 

Recovering a Control File Using a Current Copy 

Dropping Control Files 

Control Files Data Dictionary' Views 

See Also: Chapter 15, "Using Oracle-Managed Files" for 
information about creating control files that are both created and 
managed bv the Oracle Database server 



What Is a Control File? 



Every Oracle Database has a control file, which is a small binar;' file that records the 
physical structure of the database. The control file includes: 

The database name 

Names and locations of associated datafiies and ledo log files 

The timestamp of the database creation 

The current log sequence number 

Checkpoint information 

The control file must be available for writing bv the Oracle Database ser\'er whenever 
the database is open. Without the control file, the database cannot be mounted and 
recover;' is difficult. 

The control file of an Oracle Database is created at the same time as the database. Bv 
default, at least one copy of the control file is created during database creation. On 
some operating systems the default is to create multiple copies. You should create two 
or more copies of the control file during database creation. You can also create control 
files later, if you lose control files or want to change particular settings in the control 
fUes. 
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Guidelines for Control Files 



This section describes guidelines vou can use to man.ige the control files for a 
database, and contains the following topics: 

■ Provide Filenames for the Control Files 

■ Multiplex Control Files on Different Disks 

■ Back Up Control Files 

■ Manage tiie Size of Control Files 

Provide Filenames for the Control Files 

You specify control file names using the CONTROL_FILES initialization parameter in 
the database initialization parameter file (see "Creating Initial Control Files" on 
page 9-3). The instance recognizes and opens all the listed file during startup, and the 
instance writes to and maintains ail listed control files during database operation. 

If you do not specify files for C0NTROL_FILES before database creation: 

■ If vou are not using Oracle-managed files, then the database creates a control file 
and uses a default filename. The default name is operating system specific. 

■ If vou are using Oracle-managed files, then the initialization parameters you set to 
enable that feature determine the name and location of the control files, as 
described in Chapter 15, "Using Oracle-Managed Files '. 

■ If vou are using Automatic Storage Management, you can place incomplete ASM 
filenames in the DB_CREATE_FILE_DEST and DB_REC0VERY_FILE_DE3T 
initialization parameters. ASM then automatically creates control files in the 
appropriate places. See the sections "About ASM Filenames ' and "Creating a 
Database That Uses ASM" in Oracle Database Storage AdministraSor's Guide for more 
information. 

Multiplex Control Files on Different Disks 

Every Oracle Database should have at least two control files, each stored on a different 
physical disk. If a control file is damaged due to a disk failure, the associated instance 
must be shut down. Once the disk drive is repaired, the damaged control file can be 
restored using the intact copv of the control file from the other disk and the instance 
can be restarted. In this case, no media recovery is required. 

The behavior of multiplexed control files is this: 

■ The database w^rites to all filenames listed for the initialization parameter 
COWTROL_FILES in the database initiaUzation parameter file, 

■ The database reads only the first file Usted in the COWTROL_FILES parameter 
during database operation, 

■ If any of the control files become unavailable during database operation, the 
instance becomes inoperable and should be aborted. 



Note: Oracle strongly recommends that vour database has a 
minimum of two control files and that they are located on separate 
physical disks. 
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One wav to multiplex control files is to store a control file copy on every disk drive 
that stores members of redo log groups, if the redo log is multiplexed. By storing 
control files in these locations, vou minimize the risk that all control files and all 
groups of the redo log will be lost in a single disk failure. 



Back Up Control Files 



It is verv important that vou back up vour control files. This is true initially, and ever;' 
time you change the physical structure of your database. Such structural changes 
include: 

■ Adding, dropping, or renaming datafiles 

■ Adding or dropping a tablespace, or altering the read/write state of the tablespace 

■ Adding or dropping redo log files or groups 

The methods for backing up control files are discussed in "Backing Up Control FUes" 
on page 9-8. 

Manage the Size of Control Files 

The main determinants of the size of a control file are the values set for the 

MAXDATAFILES, MAXLOGFILES, MAXLOGMEMBERS, MAXLOGHISTORY, and 

MAXIWSTAWCES parameters in the CREATE DATABASE statement that created the 
associated database. Increasing the values of these parameters increases the size of a 
control file of the associated database. 

See Also: 

■ Your operating system specific Oracle documentation contains 
more information about the maximum control file size, 

■ Oracle Database SQL Language Reference for a description of the 

CREATE DATABASE statement 

Creating Control Files 

This section describes ways to create control files, and contains the following topics: 

■ Creating Initial Control Files 

■ Creating Additional Copies, Renaming, and Relocating Control Files 

■ Creating New Control Files 

Creating Initial Control Files 

The initial control files of an Oracle Database are created when vou issue the CREATE 
DATABASE statement The names of the control files are specified bv the 
COWTROL_FILES parameter in the initialization parameter file used during database 
creation. The filenames specified in COWTROL_FILES should be fuUv specified and are 
operating system specific. The following is an example of a CONTROL_FILES 
initialization parameter: 

COHTR0L_FILES = {/uOl/oracle/prod/controlOl .ctl, 
/u02/oracle/prod/ct>ritrol02.ctl, 
/uO 3 /oracle/ prod/ coritrol03 .ctl) 

If files with the specified names currentlv exist at the time of database creation, you 
must specify the COWTROLFILE REUSE clause in the CREATE DATABASE statement. 
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or else an error occurs. Also, if the size of the old control file differs from the SIZE 
parameter of the new one, you cannot use the REUSE clause. 

The size of the control file changes between some releases of Oracle Database, as well 
as when the number of files specified in the control file changes. Configuration 

parameters such as MAXLOGFILES, MAXLOGMEMBERS, MAXLOGHI STORY, 

MAXDATAFILES, and MAXINSTANCES affect control file size. 

You can subsequently change the value of the CONTROL_FILES initialization 
parameter to add more control files or to change the names or locations of existing 
control files. 

See Also: Your operating system specific Oracle documentation 
contains more information about specifying control files. 

Creating Additional Copies, Renaming, and Relocating Control Files 

You can create an additional control file copy for multiplexing by copying an existing 
control file to a new location and adding the file name to the list of control files. 
Similarly, you rename an existing control file by copying the file to its new name or 
location, and changing the file name in the control file list. In both cases, to guarantee 
that control files do not change during the procedure, shut down the database before 
copying the control file. 

To add a multiplexed copy of the current control file or to rename a control file: 

1. Shut down the database. 

2. Copy an existing control file to a new location, using operating system commands. 

3. Edit the CONTROL_FILES parameter in the database initialization parameter file 
to add the new control file name, or to change the existing control filename, 

4. Restart the database. 

Creating New Control Files 

This section discusses when and how to create new control files. 

When to Create New Control Files 

It is necessary for you to create new control files in the foUowing situations: 

■ All control files for the database haye been permanently damaged and you do not 
have a control file backup. 

■ You want to change the database name. 

For example, you would change a database name if it conflicted with another 
database name in a distributed environment. 



Note: You can change the database name and DBID (internal 
database identifier) using the DBNEWID utilit}'. See Oracle Database 
Utilities for information about using this utilit}'. 



The compatibilit}' level is set to a value that is earlier than 10,2,0, and you must 
make a change to an area of database configuration that relates to any of the 
following parameters from the CREATE DATABASE or CREATE COWTROLFILE 

commands: MAXLOGFILES, MAXLOGMEMBERS, MAXLOGHI STORY, and 

MAXINSTANCES, If compatibilit}' is 10,2,0 or later, you do not have to create new 
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control files when you make such a change; the control files automaticatlv expand, 
if necessary, to accommodate the new configuration information. 

For example, assume that when you created the database or recreated the control 
files, vou setMAXLOGFILES to 3, Suppose that now you want to add a fourth redo 
log file group to the database with the ALTER DATABASE command. If 
compatibility is set to 10.2.0 or later, you can do so and the controlfiles 
automatically expand to accommodate the new logfile information. However, 
with compatibility set earlier than 10.2.0, your ALTER DATABASE command 
would generate an error, and you would have to first create new control files. 

For information on compatibility level, see "AboutThe COMPATIBLE 
Initialization Parameter" on page 2-29, 

The CREATE CONTROLFILE Statement 

You can create anew control file for a database using the CREATE CONTROLFILE 
statement The following statement creates a new control file for the prod database (a 
database that formerly used a different database name): 

CREATE COHTROLFILE 
SET DATABASE prod 

LOGFILE GROUP 1 ( ' /u01/oracle/prod/redo01_01 . log 

' /u01/oracle/prod/redo01_02 . log 

GROUP 2 C/uOl/oracle/prod/redoOajl.log 

'/u01/oracle/pirod/redo02_02.1og 

GROUP 3 C/uOl/oracle/prod/redoOajl.log 

' /uOl/ oracle/prod/redo 03_0 2 . log 

RESBTLOGS 

DATAFILE '/uOl/oracle/prod/systemOl .dbf SIZE 3M, 
'/uOl/oracle/prod/rbsOl.dbs' SIZE 5M, 
'/uOl/oracle/prod/usersOl.dbs' SIZE 5M, 
'/uOl/oracle/prod/tempOl.dbs' SIZE 5H 
MMLOGFILES 50 
MMLOGMEMBERS 3 
HMLOGHISTORY 400 
MMDATAFILES 200 
MMINSTAHCES 6 
SRCHIVELOG; 



Cautions: 



The CREATE COHTROLFILE statement can potentially damage 
specified datafiles and redo log files. Omitting a filename can 
cause loss of the data in that file, or loss of access to the entire 
database. Use caution when issuing this statement and be sure 
to follow the instructions in "Steps for Creating New Control 
Files". 

If the database had forced logging enabled before creating the 
new control file, and you want it to continue to be enabled, 
then you must specify the FORCE LOGGIHG clause in the 
CREATE CONTROLFILE statement See "Specifying FORCE 
LOGGING Mode" on page 2-22. 



See Also: Oracle Database SQL Language Referenee describes the 
complete syntax of the CREATE CONTROLFILE statement 
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Steps for Creating New Control Files 

Complete the following steps to create a new control file. 

1. Make a list of all datafiles and redo log files of the database. 

If you follow recommendationB for control file backups as discussed in "Backing 
Up Control Files" on page 9-8, vou will already have a list of datafiles and redo 
log files that reflect the current structure of the database. However, if vou have no 
such list, executing the foUowing statements will produce one. 

SELECT MEMBER FROM V3L0GFILE; 

SELECT NAME FROM VSDATAFILE; 

SELECT VALUE FROM VSPARMETER IfflERE HAME = ■control_files ' ; 

If you have no such lists and your control file has been damaged so that the 
database cannot be opened, trv to locate all of the datafiles and redo log files that 
constitute the database. Any files not specified in step 5 are not recoverable once a 
new control file has been created. Moreover, if you omit anv of the files that make 
up the SYSTEM tablespace, you might not be able to recover the database. 

2. Shut down the database. 

If the database is open, shut down the database normaUy if possible. Use the 
IMMEDIATE or ABORT clauses only as a last resort. 

3. Back up all datafiles and redo log files of the database. 

4. Start up a new instance, but do not mount or open the database: 

STARTUP HOMOUMT 

5. Create a new control file for the database using the CREATE CONTROLFILE 
statement. 

When creating a new control file, specifv the RESETLOGS clause if vou have lost 
any redo log groups in addition to control files. In this case, vou will need to 
recover from the loss of the redo logs (step 8). You must specifv the RESETLOGS 
clause if vou have renamed the database. Otherwise, select the NORESETLOGS 
clause. 

6. Store a backup of the new control file on an offline storage device. See "Backing 
Up Control Files" on page 9-8 for instructions for creating a backup. 

7. Edit theCONTROL_FILES initialization parameter for the database to indicate all 
of the control files now part of vour database as created in step 5 (not including 
the backup control file). If vou are renaming the database, edit the DB_NAME 
parameter in your instance parameter file to specify the new name, 

8. Recover the database if necessary. If vou are not recovering the database, skip to 
step 9. 

If you are creating the control file as part of recoverv, recover the database. If the 
new control file was created using the NORESETLOGS clause (step 5), you can 
recover the database with complete, closed database recovery. 

If the new control file was created using the RESETLOGS clause, you must specify 
USING BACKUP CONTROL FILE, If you have lost online or archived redo logs or 
datafiles, use the procedures for recovering those files. 

See Also: Oracle Daiabme Backup and Recovery User's Guide for 
information about recovering vour database and methods of 
recovering a lost control file 
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9. Open the database using one of the following methods: 

■ If you did not perform recovery, or you performed complete, closed database 
Tecoverv in step 8, open tlie database normally. 

ALTES DATABASE OPEN; 

■ If you specified RE SETLOGS when creating the control file, use the ALTER 
DATABASE statement, indicating RESETLOGS. 

ALTER DATABASE OPEN HESETLOGS ; 

The database is now open and available for use. 



Troubleshooting After Creating Control Files 



After issuing the CREATE CONTROLFILE statement, vou may encounter some errors. 
This section describes the most common control file errors: 

■ Checking for Missing or Extra Files 

. Handling Errors During CREATE CONTROLFILE 



Checking for Missing or Extra Files 

After creating a new control file and using it to open the database, check the alert log 
to see if the database has detected inconsistencies between the data dictionary' and the 
control file, such as a datafile in the data dictionary' includes that the control file does 
not list. 

If a datafile exists in the data dictionary but not in the new control file, the database 
creates a placeholder entrv in the control file under the nameMISSINGnnnn, where 
nnnn is the file number in decimal. MISSINGnnnn is flagged in the control file as 
being offline and requiring media recovery. 

If the actual datafile corresponding toMISSIHGnnnn is read-only or offline normal, 
then vou can make the datafile accessible bv renaming MISSINGnnnn to the name of 
the actual datafile. If MISSINGnnnn corresponds to a datafile that was not read-oniv 
or offline normal, then you cannot use the rename operation to make the datafile 
accessible, because the datafile requires media recovery that is precluded by the 
results of RESETLOGS. In this case, vou must drop the tablespace containing the 
datafOe. 

Conversely, \i a datafUe listed in the control file is notpresent in the data dictionary, 
then the database removes references to it from the new control file. In both cases, the 
database includes an explanator}' message in the alert log to let you know what was 
found. 

Handling Errors During CREATE CONTROLFILE 

If Oracle Database sends you an error (usually error ORA- 01173, ORA-0117 6, 
ORA- 01177, ORA- 01 21 5, or ORA-01216) when you attempt to mount and open the 
database after creating a new control file, the most likely cause is that vou omitted a 
file from the CREATE CONTROLFILE statement or included one that should not have 
been listed. In this case, you should restore the files vou backed up in step 3 on 
page 9-6 and repeat the procedure from step 4, using the correct filenames. 
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UsetheALTER DATABASE BACKUP CONTROLFILE statement to back up your 
control files. You have two options: 

■ Back up the control file to a binary file (duplicate of existing control file) using the 
following statement: 

ALTER DATABASE BACKUP COHTROLFILE TO '/oracle/bacfcup/control.bkp ' ; 

■ Produce SQL statements that can later be used to re-create your control file: 

ALTER DATABASE BACKUP COHTROLFILE TO TRACE; 

This command writes a SQL script to a trace file where it can be captured and 
edited to reproduce the control file. View tlie alert log to determine the name and 
location of the trace file. 

See Also: 

■ Oracle Database Backup and Recovenj User's Guide for more 
information on backing up your control files 

■ "Viewing the Alert Log" on page 8-18 

Recovering a Control File Using a Current Copy 

This section presents ways that you can recover vour control file from a current 
backup or from a multiplexed copy. 

Recovering from Control File Corruption Using a Control File Copy 

This procedure assumes that one of the control files specified in the COWTROL_FILES 
parameter is corrupted, that the control file directory is still accessible, and that you 
have a multiplexed copv of the control file. 

1. With the instance shut down, use an operating system command to overwrite the 
bad control file with a good copy: 

% cp /u03/ora.cle/prod/coiitrolQ3 .ctl /uO 2/ oracle/prod/ controlO 2 .ctl 

2. Start SQL'Plus and open the database: 

SeL> STARTUP 

Recovering from Permanent Media Failure Using a Control File Copy 

This procedure assumes that one of the control files specified in the C0]slTR0L_FILE3 
parameter is inaccessible due to a permanent media failure and that you have a 
multiplexed copy of the control file. 

1. With the instance shut down, use an operating system command to copy the 
current copy of the control file to a new, accessible location: 

% cp /uOl/aracle/prod/ control 01 .ctl /"u04/ oracle/prod/ control 03 .ctl 

2. Edit the CONTROL_FILES parameter in the initialization parameter file to replace 
the bad location with the new location: 

C01TR0L_FILES = {/uOl/oracle/prod/controlOl .ctl, 
/u02/oracle/prod/control02.ctl, 
/u04 /oracle/ prod/ coritrol03 .ctl} 
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3. Start SQL'Pius and. open the database: 

SQL> 3TAETUP 

If vou have multiplexed control files, you can get the database started up quickly by 
editing the CONTROL_FILES initialization parameter. Remove the bad control file 
from CONTROL_FILES setting and you can restart the database immediately. Then 
you can perform the reconstruction of the bad control file and at some later time shut 
down and restart the database after editing the COHTROL_FILES initialization 
parameter to include the recovered control file. 



Dropping Control Files 



You want to drop control files from the database, for example, if the location of a 
control file is no longer appropriate. Remember that the database should have at least 
two control files at all times, 

1. Shut down the database, 

2. Edit the CONTR0L_FILES parameter in the database initialization parameter file 
to delete the old control file name. 

3. Restart the database. 



Note: This operation does not physically delete the unwanted 
control file from the disk. Use operating system commands to 
delete the unnecessar}' file after you have dropped the control file 
from the database. 



Control Files Data Dictionary Views 

The following views display information about control files: 



View 


Description 


VS DATABASE 


Displays database information from the control file 


VSCOHTROLFILE 


Lists the names of control files 


VS C0HTROLFILE_REC0RD_SECTI0H 


Displays information about control file record 

sections 


VS PARAMETER 


Displays the names of control files as specified in 

the COHTROL_FILES initialization parameter 



This example lists the names of the control files, 

SQL> SEI^CT HAME FROM V S CONTROL 1 1£; 



NAME 



/uOl/oracle/prod/controlOl.ctl 
/u02 /oracle/prod/con trol02.ctl 
/uO 3 /oracle/prod/ control 03 .ctl 
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Managing the Redo Log 



In this chapter: 

What Is the Redo Log? 

Planning the Redo Log 

Creating Redo Log Groups and Members 

Relocating and Renaming Redo Log Members 

Dropping Redo Log Groups and Members 

Forcing Log Switches 

Verifying Blocks in Redo Log Files 

Clearing a Redo Log File 

Redo Log Data Dictionary Views 

See Also: Chapter 15, "Using Oracle-Managed Files" for 
information about redo log files that are both created and managed 
by the Oracle Database seryer 



What Is the Redo Log? 



The most crucial structure for recover)' operations is the redo log, which consists of 
tvifo or more preallocated files that store all changes made to the database as they 
occur. Eyery instance of an Oracle Database has an associated redo log to protect the 
database in case of an instance failure. 



Redo Threads 



When speaking in the context of multiple database instances, the redo log for each 
database instance is also referred to as a redo thread. In typical configurations, only one 
database instance accesses an Oracle Database, so only one thread is present. In an 
Oracle Real Application Clusters environment, however, two or more instances 
concurrently access a single database and each instance has its own thread of redo. A 
separate redo thread for each instance avoids contention for a single set of redo log 
files, thereby eliminating a potential performance bottleneck. 

This chapter describes how to configure and manage the redo log on a standard 
single-instance Oracle Database. The thread number can be assumed to be 1 in all 
discussions and examples of statements. For information about redo log groups in an 
Oracle Real Application Clusters environment, please refer to Ornclc Real Application 
Clusters Administration and Deployment Guide. 
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Redo Log Contents 

Redo log files are filled with redo records. A redo record, also called a redo entry, is 
made up of a group of change vectors, each of which is a description of a change made 
to a single block in the database. For example, if you change a salar}' value in an 
employee table, you generate a redo record containing change vectors that describe 
changes to the data segment block for the table, the undo segment data block, and the 
transaction table of the undo segments. 

Redo entries record data that you can use to reconstruct all changes made to the 
database, including the undo segments. Therefore, the redo log also protects rollback 
data. When vou recover the database using redo data, the database reads the change 
vectors in the redo records and applies the changes to the relevant blocks. 

Redo records are buffered in a circular fashion in the redo log buffer of the SGA (see 
"How Oracle Database Writes to the Redo Log" on page 10-2) and are written to one of 
the redo log files bv the Log Writer (LGWR) database background process. Whenever 
a transaction is committed, LGWR writes the transaction redo records from the redo 
log buffer of the SGA to a redo log file, and assigns a system change number (SCN) to 
identifv the redo records for each committed transaction. Only when all redo records 
associated with a given transaction are safely on disk in the online logs is the user 
process notified that the transaction has been committed. 

Redo records can also be written to a redo log file before the corresponding transaction 
is committed. If the redo log buffer fills, or another transaction commits, LGWR 
flushes all of the redo log entries in the redo log buffer to a redo log file, even though 
some redo records may not be committed. If necessary, the database can roll back 
these changes. 

How Oracle Database Writes to the Redo Log 

The redo log of a database consists of two or more redo log files. The database requires 
a minimum of two files to guarantee that one is always available for writing while the 
other is being archived (if the database is in ARCHIVELOG mode). See "Managing 
Archived Redo Logs" on page 11-1 for more information, 

LGWR writes to redo log files in a circular fashion. When the current redo log file fills, 
LGWR begins writing to the next available redo log file. When the last available redo 
log file is filled, LGWR returns to the first redo log file and writes to it, starting the 
cycle again. Figure 10-1 illustrates the circular writing of the redo log file. The 
numbers next to each line indicate the sequence in which LGWR writes to each redo 
log file. 

Filled redo log files are available to LGWR for reuse depending on whether archiving 
is enabled, 

■ If archiving is disabled (the database is in HOARCHIVELOG mode), a filled redo log 
file is available after the changes recorded in it have been written to the datafiles, 

■ If archiving is enabled (the database is in ARCHIVELOG mode), a filled redo log file 
is available to LGWR after the changes recorded in it have been written to the 
datafiles and the file has been archived. 
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Figure 10-1 Reuse of Redo Log Files by LGWR 




1 , 4. 7, . 



2,5.5 



3,6.9,. 



Active (Current) and Inactive Redo Log Fiies 

Oracle Database uses only one redo log files at a time to store redo records written 
from the redo log buffer The redo log file that LGWR is actively writing to is called 
the current redo log file. 

Redo log files that are required for instance recovery are called active redo log files. 
Redo log files that are no longer required for instance recoverv are called inactive redo 
log files. 

If you have enabled archiving (the database is in ARGHIVELOG mode), then the 
database cannot reuse or overwrite an active online log file until one of the archiver 
background processes (ARCi;) has archived its contents. If archiving is disabled (the 
database is in NOARCHIVELOG mode), then when the last redo log file is full, LGWR 
continues bv ovenvriting the first available active file. 

Log Switches and Log Sequence Numbers 

A log swilch is the point at which the database stops writing to one redo log file and 
begins writing to another. Normally, a log switch occurs when the current redo log file 
is completely filled and writing must continue to the next redo log file. However, vou 
can configure log switches to occur at regular intervals, regardless of whether the 
current redo log file is completely filled. You can also force log switches manually. 

Oracle Database assigns each redo log file a new log sequence number every time a 
log switch occurs and LGWR begins writing to it. When the database archives redo log 
files, the archi\'ed log retains its log sequence niunber, A redo log file that is cycled 
back for use is given the next available log sequence number. 

Each online or archived redo log file is uniquely identified by its log sequence number. 
During crash, instance, or media recoverv. the database properlv applies redo log files 
in ascending order by using the log sequence number of the necessary archived and 
redo log files. 



Managing the Redo Log 10-3 



Planning the Redo Log 



Planning the Redo Log 



This section provides guidelines vou sliould consider when configuring a database 
instance redo log and contains the following topics: 

Multiplexing Redo Log Files 

Placing Redo Log Members on Different Disks 

Setting the Size of Redo Log Members 

Choosing the Number of Redo Log Files 

Controlling Archive Lag 



Multiplexing Redo Log Files 



To protect against a failure involving the redo log itself, Oracle Database allows a 
multiplexed redo log, meaning that two or more identical copies of the redo log can be 
automatically maintained in separate locations. For the most benefit, these locations 
should be on separate disks. Even if all copies of the redo log are on the same disk, 
however, the redundancv can help protect against I/O errors, file corruption, and so 
on. When redo log files are multiplexed, LGWR concurrentiv writes the same redo log 
information to multiple identical redo log files, thereby eliminating a single point of 
redo log failure. 

Multiplexing is implemented by creating ^rowps of redo log files. A group consists of a 
redo log file and its multiplexed copies. Each identical copy is said to be a member of 
the group. Each redo log group is defined by a number, such as group 1, group 2, and 
so on. 

Figure 10-2 Multiplexed Redo Log Files 




U/ I Group 1 
|, ■_'! Group 2 



In Figure 10-2, A_L0G1 and B_L0G1 are both members of Group 1, A_L0G2 and 
B_L0G2 are both members of Group 2, and so forth. Each member in a group must be 
exactly the same size. 

Each member of a log file group is concurrentiv active — that is, concurrentiv written to 
by LGWR — as indicated by the identical log sequence numbers assigned by LGWR. In 
Figure 10-2, first LGWR writes concurrently to bothA_LOGl andB_LOGl. Then it 
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writes concurrently to both A_L0G2 and B_L0G2, and so on. LGWR never writes 
concurrently to members of different groups (for example, to A_L0G1 and B_L0G2) 



Note: Oracle recommends that you multiplex vour redo log files. 
The loss of the log file data can be catastrophic if recoverv is 
required. Note that when you multiplex the redo log, the database 
must increase the amount of I/O that it performs. Depending on 
your configuration, this may impact overall database performance. 



Responding to Redo Log Failure 

Whenever LGWR cannot write to a member of a group, the database marks that 
member as INVALID and writes an error message to the LGWR trace file and to the 
database alert fog to indicate the problem with the inaccessible files. The specific 
reaction of LGWR when a redo log member is unavailable depends on the reason for 
the lack of availabilitv, as summarized in the table that follows. 



Condition 



LGWR Action 



LGWR can successfully write to at 
leijst one member in a group 



Writing proceeds as normal. LGWR writes to the 
available members of a group and ignores the 
unavailable members. 



LGWR cannot access the next group at Database operation temporarily halts until the group 
a log switch because the group needs becomes available or until the group is archived. 

to be archived 



All members ot the next group are 
inaccessible to LGWR at a log sivitch 
because of media failure 



Oracle Database returns an error, and the database 
instance shuts down. In this case, you may need to 
perform media recovery on the database from the 
loss of a redo log file. 

If the database checkpoint has moved beyond the lost 
redo log, media recovery is not necessary, because 
the database has saved the data recorded in the redo 
log to the datafiles. You need only drop the 
inaccessible redo log group. If the database did not 
archive the bad log, use ALTER DATABASE CLEAR 
UMARCHIVED LOG to disable archiving before the log 
can be dropped. 



All members of a group suddenly 
become inaccessible to LGWR while it 
is writing to them 



Oracle Database returns an error and the database 
instance immediately shuts down. In this case, you 
may need to perform media recovery. If the media 
containing the log is not actually lost— for example, if 
the drive for the log was inadvertently turned 
off— media recovery may not be needed. In this case, 
you need only turn the drive back on and let the 
database perform automatic instance recovery. 



Legal and illegal Configurations 

In most cases, a multiplexed redo log should be symmetrical: all groups of the redo log 
should have the same number of members. However, the database does not require 
that a multiplexed redo log be svmmetrical. For example, one group can have only one 
member, and other groups can have tivo members. This configuration protects against 
disk failures that temporarily affect some redo log members but leave others intact. 

The only requirement for an instance redo log is that it have at least two groups. 
Figure 10-3 shows legal and illegal multiplexed redo log configurations. The second 
configuration is Ulegal because it has only one group. 
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Figure 10-3 Legal and Illegal Multiplexed Redo Log Configuration 
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Placing Redo Log Members on Different Disks 

When setting up a multiplexed redo log, place members of a group on different 
physical disks. If a single disk fails, then only one member of a group becomes 
unavailable to LGWR and other members remain accessible to LGWR, so the instance 
can continue to function. 

If vou archive the redo log. spread redo log members across disks to eliminate 
contention betiveen the LGWR and ARCi; background processes. For example, if you 
have two groups of multiplexed redo log members (a duplexed redo log), place each 
member on a different disk and set vour archiving destination to a fifth disk. Doing so 
v^fill avoid contention between LGWR (writing to the members) and ARCw (reading 
the members). 
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Datafiles should also be placed on different disks from redo log files to reduce 
contention in writing data blocks and redo records. 



Setting the Size of Redo Log Members 



When setting the size of redo log files, consider whether vou will be archiving the redo 
log. Redo log files should be sized so that a filled group can be archived to a single 
unit of offline storage media (such as a tape or disk), with the least amount of space on 
the medium left unused. For example, suppose only one filled redo log group can fit 
on a tape and 49''u of the tape storage capacitv remains unused. In this case, it is better 
to decrease the size of the redo log files slightly, so that tivo log groups could be 
archived on each tape. 

All members of the same multiplexed redo log group must be the same size. Members 
of different groups can have different sizes. However, there is no advantage in varving 
file size between groups. If checkpoints are not set to occur between log switches, 
make all groups the same size to guarantee that checkpoints occur at regular intervals. 

The minimum size permitted for a redo log file is 4 MB. 

See Also: Your operating system-specific Oracle documentation. 
The default size of redo log files is operating system dependent. 



Choosing the Number of Redo Log Files 



The best way to determine the appropriate number of redo log files for a database 
instance is to test different configurations. The optimum configuration has the fewest 
groups possible without hampering LGWR from writing redo log information. 

In some cases, a database instance may require only two groups. In other situations, a 
database instance may require additional groups to guarantee that a recycled group is 
alwavs available to LGWR. During testing, the easiest way to determine whether the 
current redo log configuration is satisfactorv is to examine the contents of the LGWR 
trace file and the database alert log. If messages indicate that LGWR frequently has to 
wait for a group because a checkpoint has not completed or a group has not been 
archived, add groups. 

Consider the parameters that can limit the number of redo log files before setting up or 
altering the configuration of an instance redo log. The following parameters limit the 
number of redo log files that you can add to a database: 

■ TheMAXLOGFILES parameter used in the CREATE DATABASE statement 
determines the maximum number of groups of redo log files for each database. 
Group values can range from 1 toMAXLOGFILES. When the compatibilit}' level is 
set earlier than 10.2.0, the only way to override this upper limit is to re-create the 
database or its control file. Therefore, it is important to consider this limit before 
creating a database. When compatibilitv is set to 10.2.0 or later, you can exceed the 
MAXLOGFILES limit, and the control files expand as needed. If MAXLOGFILES is 
not specified for the CREATE DATABASE statement, then the database uses an 
operating system specific default value. 

■ The MAXLOGMEMBKRS parameter used in the CREATE DATABASE statement 
determines the maximum number of members for each group. As with 
MAXLOGFILES, the onlv way to override this upper limit is to re-create the 
database or control file. Therefore, it is important to consider this limit before 
creating a database. If noMAXLOGMEMBERS parameter is specified for the CREATE 
DATABASE statement, then the database uses an operating svstem default value. 
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See Also: 



Your operating system specific Oracle documentation for the 
default and legal values of theMAXLOGFILES and 

MAXLOGMEMBERS parameters 



Controlling Archive Lag 



You can force all enabled redo log threads to switch their current logs at regular time 
intervals. In a primarv/standby database configuration, changes are made available to 
the standby database by archiving redo logs at the primarv site and then shipping 
them to the standbv database. The changes that are being applied by the standbv 
database can lag behind the changes that are occurring on the primarv database, 
because the standbv database must wait for the changes in the primary database redo 
log to be archived (into the archived redo log) and then shipped to it To limit this lag, 
you can set the ARCHIVE_LAG_TARGET initialization parameter Setting this 
parameter lets vou specify in seconds how long that lag can be. 

Setting the ARCHIVE. LAG_TARGET Initialization Parameter 

When you set the ARCHIVE_LAG_TARGET initialization parameter, you cause the 
database to examine the current redo log of the instance periodicallv. If the following 
conditions are met, then the instance will switch the log: 

■ The current log was created prior to n seconds ago, and the estimated archival 
time for the current log is lu seconds (proportional to the number of redo blocks 
used in the current log), where n + m exceeds the value of the 
ARCHIVE_LAG_TARGET initialization parameter, 

■ The current log contains redo records. 

In an Oracle Real Application Clusters environment, the instance also causes other 
threads to switch and archive their logs if they are falling behind. This can be 
particularly useful when one instance in the cluster is more idle than the other 
instances (as when you are running a 2-node primary /secondary configuration of 
Oracle Real Application Clusters), 

The ARCHIVE_LAG_TARGET initialization parameter specifies the target of how many 
seconds of redo the standbv could lose in the event of a primarv shutdown or failure if 
the Oracle Data Guard environment is not configured in a no-data-loss mode. It also 
provides an upper limit of how long (in seconds) the current log of the primary 
database can span. Because the estimated archival time is also considered, this is not 
the exact log switch time. 

The following initialization parameter setting sets the log switch interval to 30 minutes 
(a t\'pical value), 

aECHIVE_LAG_TARGET = 1800 

A value of disables this time-based log switching functionality. This is the default 
setting. 

You can set the ARCHIVE_LAG_TARGET initialization parameter even if there is no 
standby database. For example, the ARCHIVB_LAG_TARGET parameter can be set 
specifically to force logs to be switched and archived, 

ARCHIVE_LAG_TARGET is a dynamic parameter and can be set with the ALTER 
SYSTEM SET statement 
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Caution: The ARCHIVE_LAG_TARGET parameter must be set to 
the same value in all instances of an Oracle Real Application 
Clusters environment. Failing to do so results in unpredictable 
behavior 

Factors Affecting the Setting of ARCHIVE_LAG_TARGET 

Consider the following factors when determining if vou want to set the 
ARCHIVE_LAG_TARGET parameter and in determining the value for this parameter 

■ Overhead of switching (as well as archiving) logs 

■ How frequently normal log switches occur as a result of log full conditions 

■ How much redo loss is tolerated in the standby database 

Setting ARCHIVE_LAG_TARGET may not be very useful if natural log switches already 
occur more frequently than the interval specified. However, in the case of 
irregularities of redo generation speed, the interval does provide an upper limit for the 
time range each current log covers. 

If the ARCHIVE_LAG_TARGET initialization parameter is set to a very low value, there 
can be a negative impact on performance. This can force frequent log switches. Set the 
parameter to a reasonable value so as not to degrade the performance of the primary 
database. 

Creating Redo Log Groups and Members 

Plan the redo log of a database and create all required groups and members of redo 
log files during database creation. However, there are situations where you might 
want to create additional groups or members. For example, adding groups to a redo 
log can correct redo log group availability problems. 

To create new redo log groups and members, you must have the ALTER DATABASE 
system privilege. A database can have up toMAXLOGFILES groups. 

See Also: Oracle Database SQL Language Reference for a complete 
description of the ALTER DATABASE statement 

Creating Redo Log Groups 

To create a new group of redo log files, use the SQL statement ALTER DATABASE with 
the ADD LOGFILE clause. 

The following statement adds a new group of redo logs to the database: 

ALTER DATABASE 

ADD LOGFILE ( 7oracle/dbs/loglc .rdo ' , 7oracle/iibE/log2c .rdo' ) SIZE 500K; 

Note: Use fully specify filenames of new log members to indicate 
where the operating system file should be created, Othenvise, the 
files will be created in either the default or current directory of the 
database server, depending upon your operating system. 

You can also specify the number that identifies the group using the GROUP clause: 

ALTER DATABASE 

ADD LOGFILE GROUP 10 { ' /oracle/dbs/loglcrdo ' , 7oracle/dbs/log2c .rdo ' ) 
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SIZE 500Kr 

Using group numbers can make administering redo log groups easier However, the 
group number must be between 1 andMAXLOGFILES. Do not skip redo log file group 
numbers (that is, do not number your groups 10, 20, 30, and so on), or you will 
consume unnecessar}' space in the control files of the database. 



Creating Redo Log Members 



In some cases, it might not be necessary to create a complete group of redo log files. A 
group could already exist, but not be complete because one or more members of the 
group were dropped (for example, because of a disk failure). In this case, you can add 
new members to an existing group. 

To create new redo log members for an existing group, use the SQL statement ALTER 
DATABASE with the ADD LOGFILE MEMBER clause. The following statement adds a 
new redo log member to redo log group number 2; 

ALTER DATABASE ADD LOGFILE MEMBER ' /oracle/dbs/log2b.rdo ' TO GRODP 2; 

Notice that filenames must be specified, but sizes need not be. The size of the new 
members is determined from the size of the existing members of the group. 

When using the ALTER DATABASE statement, you can alternatively identify the target 
group by specifying all of the other members of the group in the TO clause, as shown 
in the following example: 

ALTER DATABASE ADD LOGFILE MEMBER 7oracle/dbs/log2c .rdo ' 
TO ('/oracle/dbs/log2a.rdo' , 7oracle/dbE/log2b.rdo ' ) ; 



Note: Fullv specify the filenames of new log members to indicate 
where the operating system files should be created. Otherwise, the 
files will be created in either the default or current directory of the 
database server, depending upon your operating system. You may 
also note that the status of the new log member is shown as 
INVALID. This is normal and it will change to active (blank) when 
it is first used. 



Relocating and Renaming Redo Log Members 



You can use operating system commands to relocate redo logs, then use the ALTER 
DATABASE statement to make their new names (locations) known to the database. This 
procedure is necessary, for example, if the disk currently used for some redo log files 
is going to be removed, or if datafiles and a number of redo log files are stored on the 
same disk and should be separated to reduce contention. 

To rename redo log members, you must have the ALTER DATABASE system privilege. 
Additionally, you might also need operating system pri\'ileges to copy files to the 
desired location and privileges to open and back up the database. 

Before relocating your redo logs, or making any other structural changes to the 
database, completely back up the database in case you experience problems while 
performing the operation. As a precaution, after renaming or relocating a set of redo 
log files, immediately back up the database control file. 

Use the following steps for relocating redo logs. The example used to illustrate these 
steps assumes: 

■ The log files are located on two disks; diska and diskb. 
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■ The redo log is duplexed: one group consists of the members 
/diska/logs/logla.rdo and /diskb/logs/loglb .rdo, and the second 
group consists of the members / di ska/ logs /log2a. rdo and 

/ d 1 s kb /logs/log2b.rdo. 

■ The redo log files located on diska must be relocated to diskc. The new 
filenames will reflect the new location: /diskc /logs /logic, rdo and 

/ di skc/ logs/log2c.rdo. 

Steps for Renaming Redo Log Members 

1. Shut down the database. 

SHUTDOWH 

2. Copy the redo log files to the new location. 

Operating system files, such as redo log members, must be copied using the 
appropriate operating system commands. See vour operating svstem specific 
documentation for more information about copying files. 

Note: You can execute an operating svstem command to copy a 
file (or perform other operating system commands) without exiting 
SQL'Plus by using the HOST command. Some operating systems 
allow you to use a character in place of the word HOST, For 
example, you can use an exclamation point ([) in UNIX. 

The following example uses operating svstem commands (UNIX) to move the 
redo log members to a new location: 

mu" /diska/logs/logla.rdo /diskc/logs/loglc .rdo 
irra" /diEka/logs/log2a .rdo /diskc/logs/log2c .rdo 

3. Startup the database, mount, but do not open it. 

CONNECT / as 3YSDBA 
STARTUP MOUHT 

4. Rename the redo log members. 

Use the ALTER DATABASE statement with the RENAME FILE clause to rename 
the database redo log files. 

ALTER DATABASE 

RENAME FILE '/diska/logs/logla.rdo', ' /di3ka/log3/log2a.rdo' 
TO ' /diskc/logs/loglc .rdo ' , ' /diskc/ logs /log2c .rdo ' ; 

5. Open the database for normal operation. 

The redo log alterations take effect when the database is opened, 

ALTER DATABASE OPEN; 



Dropping Redo Log Groups and Members 



In some cases, vou may want to drop an entire group of redo log members. For 
example, you want to reduce the number of groups in an instance redo log. In a 
different case, you mav want to drop one or more specific redo log members. For 
example, if a disk failure occurs, vou may need to drop all the redo log files on the 
failed disk so that the database does not try to write to the inaccessible files. In other 



Managing the Redo Log 10-11 



Dropping Redo Log Groups and Members 



situations, particular redo log files become unnecessary. For example, a file might be 
stored in an inappropriate location. 



Dropping Log Groups 



To drop a redo log group, you must have the ALTER DATABASE system privilege. 
Before dropping a redo log group, consider the following restrictions and precautions; 

■ An instance requires at least two groups of redo log files, regardless of the number 
of members in the groups. (A group comprises one or more members.) 

■ You can drop a redo log group only if it is inactive. If you need to drop the current 
group, first force a log switch to occur 

■ Make sure a redo log group is archived (if archiving is enabled) before dropping 
it To see whether this has happened, use the V$LOG view. 

SELECT GEOUP#, AECHIVED, STATUS FROM V$LOG; 
GEOUP# ARC STATDS 



1 YES ACTIVE 

2 NO CURRENT 

3 YES INACTIVE 

4 YES INACTIVE 

Drop a redo log group with the SQL statement ALTER DATABASE with the DROP 
LOGFILE clause. 

The following statement drops redo log group number 3: 

ALTER DATABASE DROP LOGFILE GROUP 3; 

When a redo log group is dropped from the database, and you are not using the 
Oracle-managed files feature, the operating system files are not deleted from disk. 
Rather, the control files of the associated database are updated to drop the members of 
the group from the database structure. After dropping a redo log group, make sure 
that the drop completed successfullv, and then use the appropriate operating system 
command to delete the dropped redo log files. 

When using Oracle-managed files, the cleanup of operating systems files is done 
automatically for vou. 



Dropping Redo Log l\/lembers 



To drop a redo log member, you must have the ALTER DATABASE svstem privilege. 
Consider the following restrictions and precautions before dropping individual redo 
log members: 

■ It is permissible to drop redo log files so that a multiplexed redo log becomes 
temporarily asymmetric. For example, if you use duplexed groups of redo log 
files, vou can drop one member of one group, even though all other groups have 
two members each. However, vou should rectifv this situation immediately so that 
all groups have at least two members, and thereby eliminate the single point of 
failure possible for the redo log. 

■ An instance always requires at least two valid groups of redo log files, regardless 
of the number of members in the groups. (A group comprises one or more 
members.) If the member you want to drop is the last valid member of the group, 
you cannot drop the member until the other members become valid. To see a redo 
log file status, use the VS LOGFILE view. A redo log file becomes INVALID if the 
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database cannot access it. It becomes STALE if the database suspects that it is not 
complete or correct. A stale log file becomes valid again the next time its group is 
made the active group. 

■ You can drop a redo log member only if it is not part of an active or current group. 
If you want to drop a member of an active group, first force a log switch to occur. 

■ Make sure the group to which a redo log member belongs is archived (if archiving 
is enabled) before dropping the member To see whether this has happened, use 
the VSLOG view. 

To drop specific inactive redo log members, use the ALTER DATABASE statement with 

the DROP LOGFILE MEMBER clause. 

The following statement drops the redo log /oracle/dbs/log3c.rdo: 

ALTER DATABASE DROP LOGFILE MEMBER ' /oracle/dbs/log3c.rdo ' ; 

When a redo log member is dropped from the database, the operating system file is 
not deleted from disk. Rather, the control files of the associated database are updated 
to drop the member from the database structure. After dropping a redo log file, make 
sure that the drop completed successfully, and then use the appropriate operating 
system command to delete the dropped redo log file. 

To drop a member of an active group, you must first force a log switch. 



Forcing Log Switches 



A log switch occurs when LGWR stops writing to one redo log group and starts 
writing to another. By default, a log switch occurs automatically when the current 
redo log file group fills. 

You can force a log switch to make the currently active group inactive and available 
for redo log maintenance operations. For example, you want to drop the currently 
active group, but are not able to do so until the group is inactive. You may also wish to 
force a log switch if the currentlv active group needs to be archived at a specific time 
before the members of the group are completely filled. This option is useful in 
configurations with large redo log files that take a long time to fill. 

To force a log switch, you must have the ALTER SYSTEM privilege. Use the ALTER 
SYSTEM statement with the SWITCH LOGFILE clause. 

The following statement forces a log switch: 

ALTER SYSTEM SWITCH LOGFILE; 



Verifying Blocks in Redo Log Files 



You can configure the database to use checksums to verify blocks in the redo log files. 
If you set the initialization parameter DB_BLOCK_CHECKSUM to TYP I CAL (the default), 
the database computes a checksum for each database block when it is written to disk, 
including each redo log block as it is being written to the current log. The checksum is 
stored the header of the block. 

Oracle Database uses the checksum to detect corruption in a redo log block. The 
database verifies the redo log block when the block is read from an archived log 
during recovery and when it writes the block to an archive log file. An error is raised 
and written to the alert log if corruption is detected. 
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If corruption is detected in a redo log block while trying to archive it, the system 
attempts to read the block from another member in the group. If the block is corrupted 
in all members of the redo log group, then archiving cannot proceed. 

The value of the DB_BLOCK_CHECKSUM parameter can be changed dynamically using 
the ALTER SYSTEM statement. 



Note: There is a slight overhead and decrease in database 
performance with DB_BLOCK_CHECKSUM enabled. Monitor your 
database performance to decide if the benefit of using data block 
checksums to detect corruption outweighs the performance impact. 



See Also: Oracle Database Reference for a description of the 

DB_BLOCK_CHECKSUM initialization parameter 



Clearing a Redo Log File 



A redo log file might become corrupted while the database is open, and ultimately 
stop database activity because archiving cannot continue. In this situation the ALTER 
DATABASE CLEAR LOGFILE statement can be used to reinitialize the file without 
shutting down the database. 

The following statement clears the log files in redo log group number 3: 

ALTER DATABASE CLEAR LOGFILE GROUP 3; 

This statement overcomes two situations where dropping redo logs is not possible: 

■ If there are only two log groups 

■ The corrupt redo log file belongs to the current group 

If the corrupt redo log file has not been archived, use the UNARCHIVED keyword in the 
statement. 

ALTER DATABASE CLEAR UHARCHIVED LOGFILE GROUP 3; 

This statement clears the corrupted redo logs and avoids archiving them. The cleared 
redo logs are available for use even though they were not archived. 

If vou clear a log file that is needed for recovery of a backup, then vou can no longer 
recover from that backup. The database writes a message in the alert log describing the 
backups from which you cannot recover. 

Note: If you clear an unarchived redo log file, you should make 
another backup of the database. 

If vou want to clear an unarchived redo log that is needed to bring an offline 
tablespace online, use the UNRECOVERABLE DATAFILE clause in the ALTER 

DATABASE CLEAR LOGFILE statement. 

If VOU clear a redo log needed to bring an offline tablespace online, you will not be 
able to bring the tablespace online again. You will ha\'e to drop the tablespace or 
perform an incomplete recover}'. Note that tablespaces taken offline normal do not 
require recovery. 
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Redo Log Data Dictionary Views 

The following views provide information on redo logs. 



View Description 



V5L0G Displays the redo log file information from the control file 



V5L0GFILE Identifies redo log groups and members and member status 



VSLOG_HISTORY Contains log history information 



The following query returns the control file information about the redo log for a 
database. 

SELECT ' FROM VSLOG; 

GEOUP# THREAD* SEQ BYTES MEMBERS ARC STATUS FIRST_CHMGEtt FIRST_TIM 

1 1 10505 1048576 1 YES ACTIVE 11515628 16-APR-OO 

2 1 10506 1048576 1 MO CURREHT 11517595 16-APR-OO 

3 1 10503 1048576 1 YES INACTIVE 11511656 16-APR-OO 

4 1 10504 1048576 1 YES INACTIVE 11513647 15-APR-OO 

To see the names of all of the member of a group, use a query similar to the following 

SELECT ' FROM VSLOGFILE; 
GROUP# STATUS MEMBER 



1 D : \0RAMT\0RADATA\IDDB2 \REDO04 . LOG 

2 D : \0RAMT\0RADATA\IDDB2 \REDO03 . LOG 

3 D : \0RAMT\0RADATA\IDDB2 \REDO02 . LOG 

4 D : \0RAMT\0RADATA\IDDB2 \REDO01 . LOG 

If STATUS is blank for a member, then the file is in use. 



See Also: Oracle Database Reference for detailed information about 
these views 
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Managing Archived Redo Logs 



n this chapter: 

What Is the Archived Redo Log? 

Choosing Between NOARCHIVELOG and ARCHIVELOG Mode 

Controlling Archiving 

Specifying the Archive Destination 

Specifying the Mode of Log Transmission 

Managing Archive Destination Failure 

Controlling Trace Output Generated bv the Archivelog Process 

Viewing Information About the Archived Redo Log 

See Also: 

■ Chapter 15, "Using Oracle-Managed Files" for information 
about creating an archived redo log that is both created and 
managed by the Oracle Database server 

■ Orach Real Application Clusters Adiiiinistratioir and Deployment 
Guide for information specific to archiving in the Oracle Real 
Application Clusters environment 



What Is the Archived Redo Log? 



Oracle Database lets vou save filled groups of redo log files to one or more offline 
destinations, known collectively as the archived redo log. The process of turning redo 
log files into archived redo log files is called archiving. This process is only possible if 
the database is running in akchivelog mode. You can choose automatic or manual 
archiving. 

An archived redo log file is a copy of one of the filled members of a redo log group. It 
includes the redo entries and the unique log sequence number of the identical member 
of the redo log group. For example, if vou are multiplexing your redo log, and if group 
1 contains identical member files a_logl and b_logl, then the archiver process 
(ARCji) will archive one of these member files. Should a_logl become corrupted, 
then ARCh can still archive the identical b_logl. The archived redo log contains a 
copy of ever}' group created since you enabled archiving. 

When the database is running in ARCHIVELOG mode, the log writer process (LGWR) 
cannot reuse and hence overwrite a redo log group until it has been archived. The 
background process ARCii automates archiving operations when automatic archiving 
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is enabled. The database stiirts multiple archiver processes as needed to ensure that 
the archiving of filled redo logs does not fall behind. 

You can use archived redo logs to: 

■ Recover a database 

■ Update a standby database 

■ Get information about the historv of a database using the LogMiner utility 

See Also: The following sources document the uses for archived 
redo logs: 

■ Oracle Database Backup and Recovery User's Guide 

■ Oracle Data Guard Concepts and AdiiiinisSralion discusses setting 
up and maintaining a standby database 

■ Oracle Database Utilities contains instructions for using the 
LogMiner PL /SQL package 

Choosing Between NOARCHIVELOG and ARCHIVELOG Mode 

This section describes the issues you must consider when choosing to run vour 
database in NOARCHIVELOG or ARCHIVELOG mode, and contains these topics: 

. Running a Database in NOARCHIVELOG Mode 

. Running a Database in ARCHIVELOG Mode 

The choice of whether to enable the archiving of filled groups of redo log files depends 
on the availabiliK" and reliabilit\' requirements of the application running on the 
database. If you cannot afford to lose any data in vour database in the event of a disk 
failure, use ARCHIVELOG mode. The archiving of filled redo log files can require you 
to perform extra administrative operations. 

Running a Database in NOARCHIVELOG Mode 

When vou run your database in NOARCHIVELOG mode, you disable the archiving of 
the redo log. The database control file indicates that filled groups are not required to 
be archived. Therefore, when a filled group becomes inactive after a log switch, the 
group is available for reuse bv LGWR. 

NOARCHIVELOG mode protects a database from instance failure but not from media 
failure, Onlv the most recent changes made to the database, which are stored in the 
online redo log groups, are available for instance recovery. If a media failure occurs 
while the database is in NOARCHIVELOG mode, you can onlv restore the database to 
the point of the most recent full database backup. You cannot recover transactions 
subsequent to that backup. 

In NOARCHIVELOG mode vou cannot perform online tablespace backups, nor can you 
use online tablespace backups taken earlier while the database was in ARCHIVELOG 
mode. To restore a database operating in NOARCHIVELOG mode, vou can use onlv 
whole database backups taken while the database is closed. Therefore, if vou decide to 
operate a database in NOARCHIVELOG mode, take whole database backups at regular, 
frequent intervals. 
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Running a Database in ARCHIVELOG Mode 

When you. run a diitabase in ARCHIVELOG mode, you enable the archiving of the redo 
log. The database control file indicates that a group of filled redo log files caruiot be 
reused by LGWR until the group is archived. A filled group becomes avaUabie for 
archiving immediatelv after a redo log switch occurs. 

The archiving of filled groups has these advantages: 

■ A database backup, together with onhne and archived redo log files, guarantees 
that you can recover alt committed transactions in the event of an operating 
system or disk failure. 

■ If you keep an archived log, vou can use a backup taken whUe the database is 
open and in normal system use. 

■ You can keep a standbv database current with its original database bv 
continuously applying the original archived redo logs to the standby. 

You can configure an instance to archive filled redo log files automatically, or you can 
archive manually. For convenience and efficiency, automatic archiving is usuallv best. 
Figure 11-1 illustrates how the archiver process (ARCO in this illustration) writes filled 
redo log files to the database archived redo log. 

If all databases in a distributed database operate in ARCHIVELOG mode, you can 
perform coordinated distributed database recovery. However, if any database in a 
distributed database is in NOARCHIVELOG mode, recovery of a global distributed 
database (to make all databases consistent) is limited by the last full backup of any 
database operating in NOARCHIVELOG mode. 



Figure 1 1-1 Redo Log File Use in ARCHIVELOG Mode 
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Controlling Archiving 

This section describes how to set the archiving mode of the database and how to 
control the archiving process. The following topics are discussed: 

■ Setting the Initial Database Archiving Mode 

■ Changing the Database Archiving Mode 

■ Performing Manual Archiving 

■ Adjusting the Number of Archiver Processes 

See Also: vour Oracle operating system specific documentation 
for additional iniormation on controlling archiving modes 

Setting the Initial Database Archiving Mode 

You set the initial archiving mode as part of database creation in the CREATE 
DATABASE statement. Usually, you can use the default of NOARCHIVELOG mode at 
database creation because there is no need to archive the redo information generated 
by that process. After creating the database, decide whether to change the initial 
archiving mode. 

If vou specify ARCHIVELOG mode, vou must have initialization parameters set that 
specify the destinations for the archived redo log files (see "Specifying Archive 
Destinations" on page 11-6). 



Changing the Database Archiving Mode 



To change the archiving mode of the database, use the ALTER DATABASE statem.ent 
with the ARCHIVELOG or NOARCHIVELOG clause. To change the archiving mode, you 
must be connected to the database with administrator privileges (AS SYSDBA). 

The following steps switch the database archiving mode from NOARCHIVELOG to 

ARCHIVELOG: 

1. Shut down the database instance. 

SHUTDOWH 

An open database must first be closed and anv associated instances shut down 
before you can switch the database archiving mode. You cannot change the mode 
from ARCHIVELOG to NOARCHIVELOG if any datafiles need media recovery. 

2. Back up the database. 

Before making any major change to a database, always back up the database to 
protect against any problems. This will be your final backup of the database in 
NOARCHIVELOG m.ode and can be used if something goes wrong during the 
change to ARCHIVELOG mode. See Oracle Database Backup and Recovery User's 
Guide for information about taking database backups. 

3. Edit the initialization parameter file to include the initialization parameters that 
specify the destinations for the archived redo log files (see "Specifying Archive 
Destinations" on page 11-6). 

4. Start a new instance and mount, but do not open, the database. 

STARTUP MOtlHT 

To enable or disable archiving, the database must be mounted but not open. 
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5. Change the database archiving mode. Then open the database for normal 
operations, 

ALTES DATABASE AHCHIVELOG; 
ALTER DATABASE OPEN; 

6. Shut down the database. 

SHUTDOWN TM HRDTflT R 

7. Back up the database. 

Changing the database arcliiving mode updates the control file. After changing the 
database archiving mode, vou must back up all of your database files and control 
file. Any previous backup is no longer usable because it was taken in 

WOAECHIVELOG mode. 

See Also: Oracle Real Appliaifioii Clusters Adi)tinisf ration and 
Deployment Guide for more information about switching the 
archiving mode when using Real Application Clusters 



Performing Manual Archiving 

To operate vour database in manual archiving mode, follow the procedure shown in 
"Changing the Database Archiving Mode" on page 11^, However, when you specify 
the new mode in step 5, use the following statement: 

ALTER DATABASE AHCHIVELOG HAIUAL; 

When vou operate vour database in manual ARCHIVELOG mode, vou must archive 
inactive groups of filled redo log files or vour database operation can be temporarilv 
suspended. To archive a filled redo log group manuallv, connect with administrator 
privileges. Ensure that the database is mounted but not open. Use the ALTER SYSTEM 
statement with the ARCHIVE LOG clause to manually archive filled redo log files. The 
following statement archives all unarchived log files; 

ALTER SYSTEM ARCHIVE LOG ALL; 

When vou use manual archiving mode, you cannot specifv any standby databases in 
the archiving destinations. 

Even when automatic archiving is enabled, you can use manual archiving for such 
actions as rearchiving an inactive group of filled redo log members to another location. 
In this case, it is possible for the instance to reuse the redo log group before you have 
finished manuallv archiving, and therebv overwrite the files. If this happens, the 
database writes an error message to the alert log. 

Adjusting the Number of Archiver Processes 

TheLOG_ARCHIVE_MAX_PROCESSES initialization parameter specifies the number of 
ARC); processes that the database initially invokes. The default is two processes. There 
is usually no need specify this initialization parameter or to change its default value, 
because the database starts additional archiver processes (ARC);) as needed to ensure 
that the automatic processing of filled redo log files does not fall behind. 

How^ever, to avoid anv runtime overhead of invoking additional ARC); processes, you 
can set the L0G_ARCHIVE_MAX_PROCESSES initialization parameter to specif)' up to 
ten ARCff processes to be started at instance startup. The 

LOG_ARCHIVE_MAX_PROCESSES parameter is dynamic, and can be changed using 
the ALTER SYSTEM statement. The database must be mounted but not open. The 
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following statement increases (or decreases) the number of ARCm processes currentiv 
running: 

ALTER SYSTEM SET LOG_ARCHIVE_MftX_PR0CESSES=3; 



Specifying the Archive Destination 



Before vou can archive redo logs, vou must determine the destination to which vou 
will archive and familiarize yourself with the various destination states. The dvnamic 
performance (V$) views, listed in "Viewing Information About the Archived Redo 
Log" on page 11-14, provide alJ needed archive information. 

The following topics are contained in this section: 

■ Specif\'ing Archive Destinations 

■ Understanding Archive Destination Status 



Specifying Archive Destinations 



You can choose whether to archive redo logs to a single destination or multiplex them. 
If you want to archive only to a single destination, you specifv that destination in the 
LOG_ARCHIVE_DEST initialization parameter If yoiL want to multiplex the archived 
logs, you can choose whether to archive to up to ten locations (iLsing the 
LOG_ARCHIVE_DEST_n parameters) or to archive only to a primary and secondary 
destination (using LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST). The 
following table summarizes the multiplexing alternatives, which are further described 
in the sections that follow. 



Method 


Initialization Parameter 


Host 


Example 


1 


LOG_ARCHIVE_DES T_n 

where: 

n is an integer from 1 to 10 


Local or 

remote 


L0G_ARCHIVE_DEST_1 = 
'LOCATIOH=/diskl/arc' 

L0G_AHCHIVE_DEST_2 = ' SERVICE=standbyl ' 


2 


LOG_ARCHIVE_DEST and 
LOG_ARGHIVE_DUPLES_DEST 


Local only 


LOG_AECHIVE_DEST = '/diskl/arc' 
LOG_AECHIVE_DDPLEX_DEST = ' /disk2/ai:c ' 



See Also: 

■ Orach Database Reference for additional information about the 
initialization parameters used to control the archiving of redo 
logs 

■ Onicle Data Guard Concepts and Adniinislration for information 
about using the LOG_ARCHIVE_DEST_n initialization 
parameter for specifying a standby destination. There are 
additional keywords that can be specified with this 
initialization parameter that are not discussed in this book. 

Method 1 : Using the LOG_ARCHIVE_DEST_n Parameter 

Use the LOG_ARCHIVE_DEST_n parameter (where ii is an integer from 1 to 10) to 
specify from one to ten different destinations for archival. Each numerically suffixed 
parameter uniquely identifies an individual destination. 

You specify the location for LOG_ARCHIVE_DEST_n using the keywords explained in 
the following table: 
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Keyword Indicates Example 



LOCATION A local file system L0G_AHCHIVE_DEST_1 = 

location. ' L0CATI0H=/di3kl/arc ' 

SERVICE Remote archival L0G_ARCHIVE_DEST_2 = ' SERVICE=standbYl ' 

through Oracle Net i 
service name. ' 



If vou use the LOCATION keyword, specify a valid path name for vour operating 
system. If you specify SERVICE, the database translates the net service name through 
the tnsnames . ora file to a connect descriptor The descriptor contains the 
information necessary for connecting to the remote database. The service name must 
have an associated database SID, so that the database correctly updates the log history 
of the control file for the standbv database. 

Perform the following steps to set the destination for archived redo logs using the 
LOG_ARCHIVE_DEST_n initialization parameter: 

1 . Use SQL'PIus to shut down the database. 

SHUTDOWN 

2. Set the LOG_ARCHIVE_DEST_ii initialization parameter to specify from one to ten 
archiving locations. The LOCATION keyword specifies an operating system 
specific path name. For example, enter: 

L0G_ARCHIVE_DEST_1 = ' LOCATIOH = /di ski /archive' 
L0G_ARCHIVE_DEST_2 = 'LOCATIOH = /diska/ archive' 
L0G_ARCHIVE_DEST_3 = 'LOCATION = /diskS/ archive' 

If vou are archiving to a standby database, use the SERVICE keyword to specif}' a 
valid net service name from the tnsnames . ora file. For example, enter: 

L0G_ARCHIVE_DEST_4 = 'SERVICE = standbyl ' 

3. Optionally, set the LOG_ARCHIVE_FORMAT initialization parameter, using %t to 
include the thread number as part of the file name, %s to include the log sequence 
number, and %r to include the resetlogs ID (a timestamp value represented in 
ub4). Use capital letters {%T, %S, and %R) to pad the file name to the left with 
zeroes. 



Note: If the COMPATIBLE initialization parameter is set to 10,0,0 
or higher, the database requires the specification of resetlogs ID 
(%r) when you include the LOG_ARCHIVE_FORMAT parameter The 
default for this parameter is operating s}'stem dependent. For 
example, this is the default format for UNIX: 

LOG_ARCHIVE_FORMAT=%t_%s_%r . dbf 

The incarnation of a database changes when you open it with the 
RESETLOGS option. Specifying %r causes the database to capture 
the resetlogs ID in the archived redo log file name. See Oracle 
Database Backup and Recovery User's Guide for more information 
about this method of recoverv. 



The following example shows a setting of LOG_ARCHIVE_FORMAT: 
LOG ARCHIVE FORMAT = arch %t ^s 'Jr. arc 
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This setting will gener.ite archived logs as follows for thread 1; log sequence 
numbers 100. 101. and 102; resetlogs ID 509210197, The identical resetlogs ID 
indicates that the files are all from the same database incarnation: 

/diskl/arcMve/arch_l_100_509210197.arc, 

/diskl/archive/arch_l_101_509210197.arc, 
/diEkl/archive/arch_l_102_509210197.arc 

/diEk2/archive/arch_l_100_509210197.arc. 
/disk2/archive/arch_l_101_509210197.arc, 
/disk2/archive/arch_l_102_509210197.airc 

/diEk3/archive/arch_l_100_509210197.arc. 
/diEk3/arcMve/arch_l_101_509210197.arc, 
/diEk3/arcMve/arch_l_102_509210197.arc 

Method 2: Using LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST 

To specif)' a mnximLim of two locations, use the L0G_ARCHIVE_DE3T parameter to 
specify a primar\' archive destination and the LOG_ARCHIVE_DUPLEX_DEST to 
specify an optional secondary archive destination. All locations must be local. 
Whenever the database archives a redo log, it archives it to every destination specified 
by either set of parameters. 

Perform the following steps the use method 2: 

1. UseSQL'Plus to shut down the database. 

SHUTDOWH 

2. Specify destinations for the LOG_ARCHIVE_DEST and 
LOG_ARCHIVE_DUPLEX_DEST parameter (you can also specify 
LOG_ARCHIVE_DUPLEX_DEST dynamically using the ALTER SYSTEM statement). 
For example, enter: 

LOG_flRCHIVE_DEST = ' /diakl/archive' 

LOG_ARCHIVE_DUPLEX_DEST = 7disk2/archive ' 

3. Set the LGG_ARCHIVE_FORMAT initialization parameter as described in step 3 for 
method 1. 



Understanding Archive Destination Status 



Each archive destination has the following variable characteristics that determine its 
status: 

■ Valid/Invalid: indicates whether the disk location or service name information is 
specified and valid 

■ Enabled/Disabled: indicates the availability state of the location and whether the 
database can use the destination 

■ Active /Inactive: indicates whether there was a problem accessing the destination 

Several combinations of these characteristics are possible. To obtain the current status 
and other information about each destination for an instance, query the 

VSARCHIVE_DEST view. 

The characteristics determining a locations status that appear in the view are shown in 
Table 11—1. Note that for a destination to be used, its characteristics must be valid, 
enabled, and active. 
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Table 11-1 Destination Status 





Characteristics 






STATUS 


Valid 


Enabled 


Active 


Meaning 


VALID 


True 


, True 


True 


The user has properly initialized the 
destination, which is available for 
archiving. 


INACTIVE 


False 


n/a 


n/a 


The user has not provided or has 
deleted the destination information. 


ERROR 


True 


True 


False 


An error occurred creating or writing to 
the destination file; refer to error data. 


FULL 


True 


True 


False 


Destination is full (no disk space). 


DEFEEHED 


True 


False 


True 


The user manually and temporarily 
disabled the destination. 


DISABLED 


True 


False 


False 


The user manually and temporarily 
disabled the destination following an 
error; refer to error data. 


BAD PARAM 


n/a 


n/a 


n/a 


A parameter error occurred; refer to 
error data. 



The LOG_ARCHIVE_DEST_STATE_rj (where n is an integer from 1 to 10) initialization 
parameter lets you control the availability state of the specified destination (m), 

■ ENABLE indicates that the database can use the destination. 

■ DEFER indicates that the location is temporarily disabled. 

■ ALTERNATE indicates that the destination is an alternate. 

The availability state of the destination is DEFER, unless there is a failure of its parent 
destination, in which case its state becomes ENABLE. 

Specifying the IVIode of Log Transmission 

The two modes of transmitting archived logs to their destination are normal archiving 
transmission and standby transmission mode. Normal transmission involves 
transmitting files to a local disk. Standby transmission involves transmitting files 
through a network to either a local or remote standby database. 

Normal Transmission Mode 

In normal transmission mode, the archiving destination is another disk drive of the 
database server. In this configuration archiving does not contend with other files 
required bv the instance and can complete more quickly. Specify the destination with 
either the L0G_ARCHIVE_DEST_!3 or LOG_ARCHIVE_DEST parameters. 

It is good practice to move archived redo log files and corresponding database 
backups from the local disk to permanent inexpensive offline storage media such as 
tape. A primary value of archived logs is database recovery, so you want to ensure 
that these logs are safe should disaster strike your primar}' database. 

Standby Transmission lUlode 

In standby transmission mode, the archiving destination is either a local or remote 
standby database. 
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Caution: You can maintain a standby database on a local disk, but 
Oracle strongly encourages you to maximize disaster protection by 
m.aintaining your standby database at a remote site. 



If vou are operating your standby database in managed recovery mode, you can keep 
your standby database synchronized with your source database by automatically 
applying transmitted archived redo logs. 

To transmit files successfully to a standby database, either ARCm or a server process 
must do the following: 

■ Recognize a remote location 

■ Transmit the archived logs in conjunction with a remote file server (RFS) process 
that resides on the remote server 

Each ARC?7 process has a corresponding RFS for each standby destination. For 
example, if three ARCw processes are archiving to two standby databases, then Oracle 
Database establishes six RFS connections. 

You transmit archived logs through a network to a remote location by using Oracle 
Net Services. Indicate a remote archival by specifying a Oracle Net service name as an 
attribute of the destination, Oracle Database then translates the service name, through 
the tnsnames . ora file, to a connect descriptor The descriptor contains the 
information necessary for connecting to the remote database. The service name must 
have an associated database SID, so that the database correctly updates the log history 
of the control file for the standby database. 

The RFS process, which runs on the destination node, acts as a network server to the 
ARC); client. Essentially, ARCn pushes information to RFS, which transmits it to the 
standby database. 

The RFS process, which is required when archiving to a remote destination, is 
responsible for the following tasks: 

■ Consuming network I/O from the ARCjv process 

■ Creating file names on the standby database by using the 

STANDBY_ARCHIVE_DEST parameter 

■ Populating the log files at the remote site 

■ Updating the standby database control file (which Recovery Manager can then use 
for recover}') 

Archived redo logs are integral to maintaining a standby database, which is an exact 
replica of a database. You can operate your database in standby archiving mode, 
which automatically updates a standby database with archived redo logs from the 
original database. 

See Also: 

■ Oracle Data Gtiard Concepts and Admin/slration 

■ Oracle Database Net Services Administrator's Guide for 
information about connecting to a remote database using a 
service name 
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Sometimes archive destinations can fail, causing problems wlien you operate in 
automatic archiving mode. Oracle Database provides procedures to help you 
minimize the problems associated with destination failure. These procedures are 
discussed in the sections that follow: 

■ Specifying the Minimum Number of Successful Destinations 

■ Rearchiving to a Failed Destination 

Specifying the Minimum Number of Successful Destinations 

The optional initialization parameter LOG_ARCHIVE_MIN_SUCCEED_DEST=n 
determines the minimum number of destinations to which the database must 
successf ullv archive a redo log group before it can reuse online log files. The default 
value is 1. Valid values for n are 1 to 2 if vou are using duplexing, or 1 to 10 if you aie 
multiplexing. 

Specifying Mandatory and Optionai Destinations 

The LOG_ARGHIVE_DEST_n parameter lets you specifv whether a destination is 

OPTIONAL (the default) or MANDATORY, The LOG_AECHIVE_MIN_SUCCEED_DEST=n 

parameter uses all MANDATORY destinations plus some number of non-standby 
OPTIONAL destinations to determine whether LGWR can overwrite the online log. The 
following rules applv: 

■ Omitting the MANDATORY attribute for a destination is the same as specifying 

OPTIONAL, 

■ You must have at least one local destination, which you can declare OPTIONAL or 

MANDATORY, 

■ When you specify a value for LOG_ARCHIVE_MIN_SUCCEED_DEST=n, Oracle 
Database will treat at least one local destination as MANDATORY, because the 

minimum value for LOG_ARCHIVE_MIN_SUCCEED_DE ST is 1, 

■ If any MANDATORY destination fails, including a MANDATORY standby destination, 
Oracle Database ignores the LOG_ARCHIVE_MIN_SUCCEED_DEST parameter, 

■ The L0G_ARCHIVE_MIN_SUCCEED_DE3T value cannot be greater than the 
number of destinations, nor can it be greater than the number of MANDATORY 
destinations plus the number of OPTIONAL local destinations, 

■ If vou DEFER a MANDATORY destiniition, and the database overwrites the online 
log without transferring the archived log to the standby site, then you must 
transfer the log to the standby manuallv. 

If vou are duplexing the archived logs, you can establish which destinations are 
mandatory or optional by using the LOG_ARCHIVE_DEST and 
LOG_AECHIVE_DUPLEX_DEST parameters. The following rules apply: 

■ Any destination declared by LOG_ARCHIVE_DEST is mandator^', 

■ Any destination declared by LOG_ARCHIVE_DUPLEX_DEST is optional if 

LOG_ARCHIVE_MIN_SUCCEED_DEST = 1 and mandatory if 

LOG ARCHIVE MIN SUCCEED DEST = 2, 
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Specifying tlie Number of Successfui Destinations: Scenarios 

YoLL can see the relationship betiveen the LOG_ARCHIVE_DEST_ii and 
LOG_ARCHIVE_MIN_SUCCEED_DEST parameters most easily tlirough sample 
scenarios. 

Scenario for Archiving to Optional Local Destinations In this scenario, you archive to three 
local destinations, each of which you declare as OPTIONAL. Table 11-2 illustrates the 
possible values for LOG_ARCHIVE_MIN_SUCCEED_DEST=n in this case. 

Table 11-2 LOG ARCHIVE MIN SUCCEED DEBT Values for Scenario 1 



Value Meaning 



The database can reuse log files only if at least one of the OPTIONAL 
destinations succeeds. 



The database can reuse log files only if at least two of the OPTIOHAL 
destinations succeed. 



The database can reuse log files only if all of the OPTIONAL destinations 
succeed. 



4 or greater ERROR: The value is greater than the number of destinations. 



This scenario shows that even though vou do not explicitly set anv of your 
destinations to MANDATORY using the LOG_ARCHIVE_DEST_!] parameter, the database 
must successfullv archive to one or more of these locations when 

LOG_ARCHIVE_MIN_SUCCEED_DEST is set to 1, 2, or 3. 

Scenario for Archiving to Both Mandatory and Optional Destinations Consider a case in which: 

■ You specify two MANDATORY destinations. 

■ You specify tivo OPTIONAL destinations. 

■ No destination is a standby database. 

Table 11-3 shovifs the possible values for LOG_ARCHIVE_MIN_SUCCEED_DEST=u. 

Table 11-3 LOG_ARCHIVE_MIN_SUCCEED_DEST Values for Scenario 2 
Value Meaning 



The database ignores the value and uses the number of MANDATORY 
destinations (in this example, 2), 



The database can reuse log files even if no OPTIONAL destination 
succeeds. 



The database can reuse logs only if at least one OPTIOHAL destination 
succeeds. 



4 The database can reuse logs only if both OPTIONAL destinations succeed, 

5 or greater ERROR: The value is greater than the number of destinations. 

This case shows that the database must archive to the destinations you specifv as 
MANDATORY, regardless of whether you set L0G_ARCHIVE_MIN_3UCCEED_DEST to 
archive to a smaller number of destinations. 
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Rearchiving to a Failed Destination 

Use the REOPEN attribute of the LOG_ARCHIVE_DEST_i] parameter to specif}' whether 
and when ARCi; should attempt to rearchive to a failed destination following an error. 
REOPEN applies to aU errors, not just OPEN errors. 

REOPEN=n sets the minimum number of seconds before ARC?7 should tn' to reopen a 
failed destination. The default value for ri is 300 seconds. A value of is the same as 
turning off the REOPEN attribute; ARC); will not attempt to archive after a failure. If 
you do not specif}' the REOPEN keyword, ARCn will never reopen a destination 
following an error. 

You cannot use REOPEN to specifv the number of attempts ARCw should make to 
reconnect and transfer archived logs. The REOPEN attempt either succeeds or fails. 

When you specify RBOPBN for an OPTIONAL destination, the database can overwrite 
online logs if there is an error If vou specifv REOPEN for a MANDATORY destination, the 
database stalls the production database when it cannot successfully archive. In this 
situation, consider the following options: 

■ Archive manually to the failed destination. 

■ Change the destination bv deferring the destination, specifying the destination as 
optional, or changing the service. 

■ Drop the destination. 

When using the REOPEN keyword, note the following: 

■ ARC); reopens a destination only when stnrfiiig an archive operation from the 
beginning of the log file, never during a current operation. ARCi; always retries the 
log copy from the beginning. 

■ If vou specified REOPEN, either with a specified time the default, ARCh checks to 
see w^hether the time of the recorded error plus the REOPEN interval is less than 
the current time. If it is, ARCh retries the log copy. 

■ The REOPEN clause successfully affects the ACTIVE=TRUE destination state. The 
VALID and ENABLED states are not changed. 

Controlling Trace Output Generated by the Archivelog Process 

Background processes always write to a trace file when appropriate. (See the 
discussion of this topic in "Monitoring Errors with Trace Files and the Alert Log" on 
page 7-1.) In the case of the archivelog process, you can control the output that is 
generated to the trace file. You do this by setting the LOG_ARCHIVE_TRACE 
initialization parameter to specifv a trace level. The following values can be specified: 



Trace Level 


Meaning 





Disable archivelog tracing. This is the default. 


1 


Track archival of redo log file. 


j 2 


Track archival status for each archivelog destination. 


■ 4 


Track archival operational phase. 


8 


Track archivelog destination activity. 


i 16 


Track detailed archivelog destination activitv. 


, 32 


Track archivelog destination parameter modifications. 
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Trace Level 


Meaning 


64 


Track ARCn process state activity 


128 


Track FAL (fetch archived log) server related activities. 


256 


Supported in a future release. 


512 


Tracks asynchronous LGWR activity. 


1024 


RFS physical cUent tracking, 


2048 


ARCn /RFS heartbeat tracking. 


4096 


Track real-time apply 


8192 


Track redo apply activity (media recovery or physical standby) i 



You can combine tracing levels by specifying a value equal to the sum of the 
individual levels that you would like to trace. For example, setting 
L0G_ARCHIVE_TEACE=12, will generate trace level 8 and 4 output. You can set 
different values for the primary and any standby database. 

The default value for the LOG_ARCHIVE_TRACE parameter isO, At this level, the 
archivelog process generates appropriate alert and trace entries for error conditions. 

You can change the value of this parameter dynamically using the ALTER SYSTEM 
statement. The database must be mounted but not open. For example: 

ALTER SYSTEM SET L!!G_ARCHIVE_TRACE=12 ; 

Changes initiated in this manner will take effect at the start of the next archiving 
operation. 

See Also: Oracle Data Guard Concepts and Adviinistraiion for 
inform.alion about using this parameter with a standby database 



Viewing Information About the Archived Redo Log 



You can display information about the archived redo log using dynamic performance 
views or the ARCHIVE LOG LIST command. 

This section contains the following topics: 

■ Archived Redo Logs Views 

. The ARCHIVE LOG LIST Command 



Archived Redo Logs Views 



Se\'eral d\'namic performance views contain useful information about archiyed redo 
logs, as summarized in the following table. 



Dynamic Performance View Description 


VS DATABASE 


Shows if the database is in ARCHIVELOG or NOARCHIVELOG 
mode and if MAHUAL (archiving mode) has been specified. 


VSARCHIVED_LOG 


Displays historical archived log information from the 
control file. If you use a recovery catalog, the 
RC_ARCHIVED_LOG view contains similar information. 


VSARCHIVE_I>EST 


Describes the current instance, all archive destinations, and 
the current value, mode, and status of these destinations. 
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Dynamic Performance View Description 


VSARCHIVE_PROCESSES 


Displays information about the state of the various archive 
processes for an instance. 


VS BACKUP_RED0LOG 


Contains mformation about any backups of archived logs. If 
you use a recovery catalog, the RC_BACKUP_REDOLOG 
contains similar information. 


VSLOG 


Displays all redo log groups for the database and indicates 
which need to be archived. 


VSLOG_HISTORY 


Contains log history information such as which fogs have 
been archived and the SCN range for each archived log. 



For example, the following query displays which redo log group requires archiving: 

SELECT GEOUP#. ARCHIVED 
FROM SYS. VSLOG; 



GEODPt 



ARC 



1 YES 

2 NO 



To see the current archiving mode, query the V$ DATABASE view; 

SELECT LOG_MODE FROM SYS .VSDATABASE; 



LOG MODE 



NOARCHrVELOG 



See Also: Oracle Database Reference for detailed descriptions of 
dynamic performance views 



The ARCHIVE LOG LIST Command 



The SQL'^Plus command ARCHIVE LOG LI ST displays archiving information for the 
connected instance. For example: 



SQL> ARCHIVE LOG LIST 

Database log mode 
Automatic archival 
Archive destination 
Oldest online log sequence 
Next log secfuence to archive 
Current log sequence 



Archive Mode 
Enabled 

D : \oracle\oradata\IDDB2 \ar chive 

11160 

11163 

11163 



This displav tells you all the necessary information regarding the archived redo log 
settings for the current instance: 

The database is currently operating in ARCHIVELOG mode. 

Automatic archiving is enabled. 

The archived redo log destination is D:\oracle\oradata\lDDB2\archive. 

The oldest filled redo log group has a sequence number of 11160. 

The next filled redo log group to archive has a sequence number of 11163, 

The current redo log file has a sequence number of 11163, 
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See Also: SQL*Phis User's Guide and Reference for more 
information on the ARCHIVE LOG LIST command 
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Managing Tablespaces 



In this chapter: 

GuideUnes for Managing Tablespaces 

CreatingTablespaces 

Specifying Nonstandard Block Sizes for Tablespaces 

Controlling the Writing of Redo Records 

Altering Tablespace Availability 

Using Read-Onlv Tablespaces 

Altering and Maintaining Tablespaces 

Renaming Tablespaces 

Dropping Tablespaces 

Managing the SYSAUX Tablespace 

Diagnosing and Repairing Locally Managed Tablespace Problems 

Migrating the SYSTEM Tablespace to a Locally Managed Tablespace 

Transporting Tablespaces Between Databases 

Tablespace Data Dictionary Views 

See Also: Chapter 15, "Using Oracle-Managed Files" for 
information about creating datafiles and tempfiles that are both 
created and managed by the Oracle Database server 

Guidelines for l\/lanaging Tablespaces 

Before working with tablespaces of an Oracle Database, familiarize yourself with the 
guidelines provided in the following sections: 

■ Using Multiple Tablespaces 

■ Assigning Tablespace Quotas to Users 

See Also: Oracle Database Concepts for a complete discussion of 
database structure, space management, tablespaces, and datafiles 

Using Multiple Tablespaces 

Using multiple tablespaces allows vou more flexibility in performing database 
operations. When a database has multiple tablespaces, you can: 
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■ Separate user data from data dictionary data to reduce I/O contention, 

■ Separate data of one application from the data of another to prevent multiple 
applications from being affected if a tahlespace must he taken offline. 

■ Store the datafiles of different ttibiespaces on different disk drives to reduce I/O 
contention. 

■ Take individual tablespaces offline while others remain online, providing better 
overall availability. 

■ Optimizing tablespace use by reserving a tablespace for a particular type of 
database use. such as high update activity, read-only activity, or temporar}' 
segment storage. 

■ Back up individual tablespaces. 

Some operating systems set a limit on the number of files that can be open 
simultaneously. Such limits can affect the number of tablespaces that can be 
simultaneously online. To avoid exceeding vour operating svstem limit, plan your 
tablespaces efficiently. Create only enough tablespaces to fulfill your needs, and create 
these tablespaces with as few files as possible. If you need to increase the size of a 
tablespace, add one or two large datafiles, or create datafiles with autoextension 
enabled, rather than creating manv small datafiles. 

Review vour data in light of these factors and decide how manv tablespaces you need 
for vour database design. 



Assigning Tablespace Quotas to Users 



Grant to users who will be creating tables, clusters, materialized views, indexes, and 
other objects the privilege to create the object and a quota (space allo^vance or limit) in 
the tablespace intended to hold the object segment. 

See Also: Oracle Database Seairiiy Guide for information about 
creating users and assigning tablespace quotas. 



Creating Tablespaces 



Before you can create a tahlespace, you must create a database to contain it. The 
primar}' tablespace in anv database is the SYSTEM tablespace, which contains 
information basic to the functioning of the database server, such as the data dictionary 
and the svstem rollback segment. The SYSTEM tablespace is the first tablespace created 
at database creation. It is managed as any other tablespace, but requires a higher level 
of privilege and is restricted in some wavs. For example, you cannot rename or drop 
the SYSTEM tablespace or take it offhne. 

The SYSAUX tablespace, which acts as an auxUiary tablespace to the SYSTEM 
tablespace, is also always created when vou create a database. It contains information 
about and the schemas used by various Oracle products and features, so that those 
products do not require their own tablespaces. As for the SYSTEM tablespace, 
management of the SYSAUX tablespace requires a higher level of security and you 
cannot rename or drop it. The management of the SYSAUX tablespace is discussed 
separately in "Managing the SYSAUX Tablespace" on page 12-25, 

The steps for creating tablespaces vary by operating svstem, but the first step is always 
to use vour operating svstem to create a directory structure in which vour datafiles 
will be allocated. On most operating systems, vou specify the size and fully specified 
filenames of datafiles when vou create a new tablespace or alter an existing tablespace 
by adding datafiles. Whether you are creating a new tablespace or modifying an 
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existing one, the database automatically allocates and formats the datafiles as 
specified. 

To create a new tablespace, use the SQL statement CREATE TABLE SPACE or CREATE 
TEMPORARY TABLESPACE. You must liave tlie CREATE TABLESPACE system 
privilege to create a tablespace. Later, yon can use the ALTER TABLESPACE or ALTER 
DATABASE statements to alter the tablespace. You must have tlie ALTER TABLESPACE 
or ALTER DATABASE system privilege, correspondingly. 

You can also use the CREATE UWDO TABLESPACE statement to create a special t\'pe of 
tiiblespace called an undo lablespace. which is specifically designed to contain undo 
records. These are records generated bv the database that are used to roll back, or 
undo, changes to the database for recovery, read consistency, or as requested bv a 
ROLLBACK statement. Creating and managing undo tablespaces is the subject of 
Chapter 14, "Managing Undo". 

The creation and maintenance of permanent and temporary tablespaces are discussed 
in the following sections: 

Locally Managed Tablespaces 

Bigfile Tablespaces 

Encrypted Tablespaces 

Temporary Tablespaces 

Midtiple Temporary Tablespaces: Using Tablespace Groups 

See Also: 

■ Chapter 2, "Creating and Configuring an Oracle Database" and 
your Oracle Database installation documentation for your 
operating system for information about tablespaces that are 
created at database creation 

■ Orack' Database SQL Language Reference for more information 
about the syntax and semantics of the CREATE TABLESPACE, 

CREATE TEMPORARY TABLESPACE, ALTER TABLESPACE, 

and ALTER DATABASE statements. 

■ "Specifying Database Block Sizes" on page 2-27 for information 
about initialization parameters necessar;' to create tablespaces 
with nonstandard block sizes 



Locally Managed Tablespaces 



Locally managed tablespaces track all extent information in the tablespace itself by 
using bitmaps, resulting in the following benefits: 

■ Fast, concurrent space operations. Space allocations and deallocations modify 
locally managed resources (bitn\aps stored in header files). 

■ Enhanced performance 

■ Readable standby databases are allowed, because locally managed temporary 
tablespaces do not generate any undo or redo. 

■ Space allocation is simplified, because when the AUTOALLOCATE clause is 
specified, the database automatically selects the appropriate extent size, 

■ User reliance on the data dictionarv is reduced, because the necessary information 
is stored in file headers and bitmap blocks. 
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■ Coalescing free extents is unnecessary for locally managed tablespaces. 

All tablespaces, including the SYSTEM tablespace, can be locally managed. 

The DBMS_SPACE_ADMIN package provides maintenance procedures for locally 
managed tablespaces. 

See Also: 

■ "Creating a Locally Managed SYSTEM Tablespace" on 
page 2-15, "Migrating the SYSTEM Tablespace to a Locally 
Managed Tablespace" on page 12-29, and "Diagnosing and 
Repairing Locally Managed Tablespace Problems" on 
page 12-26 

■ "Bigfile Tablespaces" on page 12-6 for information about 
creating another t\'pe of locally managed tablespace that 
contains onlv a single datafile or tempfile. 

■ Oracle Database PL/SQL Packages and Types Reference for 
information on the DBMS_SPACE_ADMIN package 

Creating a Locally Managed Tablespace 

Create a locally managed tablespace by specifying LOCAL in the EXTENT 
MANAGEMENT clause of the CREATE TABLESPACE statement This is the default for 
new permanent tablespaces, but you must specify the EXTENT MANAGEMENT LOCAL 
clause if you want to specify either the AUTOALLOCATE clause or the UNIFORM clause. 
You can have the database manage extents for you automatically with the 
AUTOALLOCATE clause (the default), or you can specify that the tablespace is managed 
with uniform extents of a specific size (UNIFORM), 

If you expect the tablespace to contain objects of varying sizes requiring many extents 
with different extent sizes, then AUTOALLOCATE is the best choice, AUTOALLOCATE is 
also a good choice if it is not important for you to have a lot of control over space 
allocation and deallocation, because it simplifies tablespace management. Some space 
may be wasted with this setting, but the benefit of having Oracle Database manage 
your space most likely outweighs this drawback. 

If vou want exact control over unused space, and vou can predict exactly the space to 
be allocated for an object or objects and the number and size of extents, then UNIFORM 
is a good choice. This setting ensures that you will never have unusable space in your 
tablespace. 

When you do not explicitly specif}' the type of extent management, Oracle Database 
determines extent management as follows: 

■ If the CREATE TABLESPACE statement omits the DEFAULT storage clause, then 
the database creates a locally managed autoallocated tablespace. 

■ If the CREATE TABLESPACE statement includes a DEFAULT storage clause, then 
the database considers the following: 

- If you specified the MINIMUM EXTENT clause, the database evaluates whether 
the values of MINIMUM EXTENT, INITIAL, and NEXT are equal and the value 
of PCTINCREA3E is 0. If SO, the database creates a locally managed uniform 
tablespace with extent size = INITIAL, If the MINIMUM EXTENT, INITIAL, 
and NEXT parameters are not equal, or if PCTINCREASE is not 0, the database 
ignores any extent storage parameters you may specify and creates a locally 
managed, autoallocated tablespace. 
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- If you did not specify MINIMUM EXTENT clause, the database evaluates onlv 
whettier the storage values of INITIAL and NEXT are equal and 
PCTINCREASE is 0. If SO, the tablespace is locally managed and uniform. 
Otherwise, the tablespace is locally managed and autoallocated. 

The following statement creates a locally managed tablespace named Imtbsb and 
specifies AUTOALLOCATE: 

CREATE TABLESPACE Imtbsb DATAFILE 7u02/oracle/data/lmtbsb01.dbf' SIZE 50M 
EXTENT MMAGEMENT LOCAL AUTOALLOCATE; 

AUTOALLOCATE causes the tablespace to be system managed with a minimum extent 
size of 64K. 

The alternative to AUTOALLOCATE is UNIFORM, which specifies that the tablespace is 
managed with extents of uniform size. You can specify that size in the SIZE clause of 
UNIFORM. If you omit SIZE, then the default size is IM. 

The following example creates a tablespace with uniform 128K extents. (In a database 
with 2K blocks, each extent would be equivalent to 64 database blocks). Each 128K 
extent is represented by a bit in the extent bitmap for this file. 

CREATE TABLESPACE Imtbsb DATAFILE 7u02/oracle/data/lmtbsb01.dbf' SIZE 50M 
EXTENT MMAGEMENT LOCAL UNIFORM SIZE 128Kr 

You carmot specify the DEFAULT storage clause, MINIMUM EXTENT, or TEMPORARY 
when you explicitly specify EXTENT MANAGEMENT LOCAL. If you want to create a 
temporary locally managed tablespace, use the CREATE TEMPORARY TABLESPACE 
statement. 



Note: When you allocate a datafile for a locally managed 
tablespace, you should allow space for metadata used for space 
management (the extent bitmap or space header segment) which 
are part of user space. For example, if specify the UNIFORM clause 
in the extent management clause but you omit the SI ZE parameter, 
then the default extent size is 1MB, In that case, the size specified 
for the datafile must be larger (at least one block plus space for the 
bitmap) than 1MB, 

Specifying Segment Space Management in Localiy Managed Tabiespaces 

In a locally managed tablespace, there are two methods that Oracle Database can use 
to manage segment space: automatic and manual. Manual segment space management 
uses linked lists called "freelists" to manage free space in the segment, while automatic 
segment space management uses bitmaps. Automatic segment space management is 
the more efficient method, and is the default for all new permanent, locally managed 
tablespaces. 

Automatic segment space management delivers better space utilization than manual 
segment space management. It is also self-tuning, in that it scales with increasing 
number of users or instances. In an Oracle Real Application Clusters environment, 
automatic segment space management allows for a dvnamic affinit}' of space to 
instances. In addition, for manv standard workloads, application performance with 
automatic segment space management is better than the performance of a well-tuned 
application using manual segment space management. 

Although automatic segment space management is the default for all new permanent, 
locallv managed tablespaces, you can explicitly enable it with the SEGMENT SPACE 

MANAGEMENT AUTO clause. 
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The following statement creates tablespace Imtbsb with automatic segm.ent space 
management: 

OffiATE TABLESPACE Imtbsb DATAFILE 7-uO2/aracle/data/lmtbsb01.dbf ' SIZE 50M 
EXTENT MMAGEMENT LOCAL 
SEGMENT SPACE MANAGEMENT ADTO; 

The SEGMENT SPACE MAMAGEMENT MANUAL clause disables automatic segment 
spiice management. 

The segment space management that you specih' at tablespace creation time applies to 
all segments subsequently created in the tablespace. You cannot change the segment 
spiice management mode of a tablespace. 



Notes: 



If vou set extent management to LOCAL UKIFORM, then vou 
must ensure that each extent contains at least 5 database blocks. 

If you set extent management to LOCAL AUTOALLOCATE, and if 
the database block size is 16K or greater, then Oracle manages 
segment space by creating extents with a minimum size of 5 
blocks rounded up to 64K. 



Locally managed tablespaces using automatic segment space management can be 
created as single-file or bigfile tablespaces, as described in "Bigfile Tablespaces" on 
page 12-6. 



Bigfile Tablespaces 



A bigfile tablespace is a tablespace with a single, but very large (up to 4G blocks) 
datafile. Traditional smallfile tablespaces, in contrast, can contain multiple datafiles, 
but the files cannot be as large. The benefits of bigfile tablespaces are the following: 

■ A bigfile tablespace with 8K blocks can contain a 32 terabyte datafile. A bigfile 
tiiblespace with 32K blocks can contain a 128 terabyte datafile. The maximum 
number of datafiles in an Oracle Database is limited (usually to 64K files). 
Therefore, bigfile tablespaces can significantly enhance the storage capacity of an 
Oracle Database. 

■ Bigfile tablespaces can reduce the number of datafiles needed for a database. An 
additional benefit is that the DB_FILES initialization parameter and 
MAXDATAFILES parameter of the CREATE DATABASE and CREATE 
COWTROLFILE statements can be adjusted to reduce the amount of SGA space 
required for datafile information and the size of the control file. 

■ Bigfile tablespaces simplif\' database management by proyiding datafile 
transparency. SQL syntax for the ALTER TABLESPACE statement lets you perform 
operations on tablespaces, rather than the underlying indiyidual datafiles, 

Bigfile tablespaces are supported only for locally managed tablespaces with automatic 
segment space management, with three exceptions: locally managed undo tablespaces, 
temporary tablespaces, and the SYSTEM tablespace. 
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Notes: 



Bigfile tablespaces are intended to be used with Automatic 
Storage Management (ASM) or other logical volume managers 
that supports striping or RAID, and dynamically extensible 
logical volumes. 

Avoid creating bigfile tablespaces on a svstem that does not 
support striping because of negative implications for parallel 
querj' execution and RMAN backup paralielization. 

Using bigfile tablespaces on platforms that do not support large 
file sizes is not recommended and can limit tablespace capacitv. 
Refer to your operating svstem specific documentation for 
iiiform.alion. about m.aximuin supported file sizes. 



Creating a Bigfile Tabiespace 

To create a bigfile tablespace, specifv the BIGFILE keyword of the CREATE 
TABLESPACE statement (CREATE BIGFILE TABLESPACE ...), Oracle Database 
automatically creates a locally managed tablespace with automatic segment space 
management. You can, but need not, specify EXTEHT MANAGEMEHT LOCAL and 
SEGMENT SPACE MANAGEMENT AUTO in this statement. However, the database returns 
an error if you specify EXTENT MANAGEMENT DICTIONARY or SEGMENT SPACE 
MANAGEMENT MANUAL. The remaining syntax of the statement is the same as for the 
CREATE TABLESPACE statement, but vou can only specifv one datafile. For example: 

CREATE BIGFILE TABLESPACE bigtbs 

DATAFILE ' /u02 /oracle/data/bigtbsOl .dbf SIZE 50G 



You can specifv SIZE in kilobytes (K), megabytes (M), gigabytes (G), or terabytes (T). 

If the default tablespace type was set to BIGFILE at database creation, vou need not 
specify the keyword BIGFILE in the CREATE TABLESPACE statement. A bigfile 
tiiblespace is created by default. 

If the default tablespace t\'pe was set to BIGFILE at database creation, but vou want to 
create a traditional (smallfile) tablespace, then specify a CREATE SMALLFILE 
TABLESPACE statement to override the default tablespace t\'pe for the tablespace that 
you are creating. 

See Also: "Supporting Bigfile Tablespaces During Database 
Creation" on page 2-20 

Identifying a Bigfile Tablespace 

The following views contain a BIGFILE column that identifies a tabiespace as a bigfile 
tablespace: 

■ DBA_TABLE SPACES 

■ USER_TABLE SPACES 

■ V$TABLESPACE 

You can also identify a bigfile tablespace bv the relative file number of its single 
datafile. That number is 1024 on most platforms, but 4096 on OS/390. 
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Encrypted Tablespaces 



You can encrypt anv permanent tablespace to protect sensitive data. Tablespace 
encryption is completely transparent to vour applications, so no application 
modification is necessary. Encrypted tablespaces primarily protect your data from 
unauffiorized access by means other than through the database. For example, when 
encrypted tablespaces are written to backup media for travel from one Oracle database 
to another or for travel to an off-site facility for storage, they remain encrypted. Also, 
encrypted tablespaces protect data from users who tr}' to circumvent the security 
features of the database and access database files directly through the operating 
system file system. 

Tablespace encryption does not address all security issues. It does not, for example, 
provide access control from within the database. Any user who is granted privileges 
on objects stored in an encrypted tablespace can access those objects without 
providing any kind of additional password or key. 

When you encrypt a tablespace, all tablespace blocks are encn'pted. All segment t\'pes 
are supported for encn'ption, including tables, clusters, indexes, LOBs (BA3ICFILE 
and SECUREFILE), table and index partitions, and so on. 

Note: There is no need to use LOB encryption on SECUREFILE LOBs 
stored in an encrypted tablespace. 



To maximize security, data from an encr}'pted tablespace is automatically encrypted 
when written to the undo tablespace, to the redo logs, and to any temporary 
tablespace. There is no need to explicitly create encrypted undo or temporary 
tablespaces, and in fact, you cannot specify encryption for those tablespace types. 

For partitioned tables and indexes that have different partitions in different 
tablespaces, it is permitted to use both encrypted and non-encrypted tablespaces in the 
same table or index. 

Tablespace encryption uses the transparent data encryption feature of Oracle 
Database, which requires that you create an Orack wallet to store the master 
encryption key for the database. The wallet must be open before you can create the 
encrypted tablespace and before you can store or retrieve encrypted data. When you 
open the wallet, it is available to all session, and it remains open until you explicitly 
close it or until the database is shut down. 

To encrypt a tablespace, you must open the database with the COMPATIBLE 
initialization parameter set to 11.1.0 or higher. The default setting for COMPATIBLE for 
a new Oracle Database llg Release 1 installation is 11.1.0. Any user who can create a 
tablespace can create an encrypted tablespace. 

Transparent data encryption supports industry- standard encryption algorithms, 
including the following Advanced Encryption Standard (AES) and Triple Data 
Encryption Standard (3DES) algorithms: 

. 3DES168 

. AES128 

. AES192 

. AES256 

The encryption key length is implied by the algorithm name. For example, the AES128 
algorithm uses 128-bit keys. You specify the algorithm to use when you create the 
tablespace, and different tablespaces can use different algorithms. Although longer 
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kev lengths theoretically provide greater security', tliere is a trade-off in CPU 
overhead. If you do not specify the algorithm in your CREATE TABLE SPACE 
statement, AES128 is the default. There is no disk space overhead for encrypting a 
table space. 

Examples 

The following statement creates an encrvpted tablespace with the default encryption 
algorithm: 

CREATE TABLESPACE securespace 

EATAFILE ' /uOl/app/oracle/oradata/orcl/secureOl .dbf SIZE lOOM 

ENCRYPTIDM 

DEFAULT STORAGE (ENCRYPT) ; 

The following statement creates the same tablespace with the AES256 algorithm: 

CREATE TABLESPACE securespace 

EATAFILE ' /uOl/app/oracle/oradata/orcl/secureOl .dbf SIZE lOOM 

ENCRYPTIOH USING ■AES256' 

DEFAULT STORAGE[E!JCR¥PT] ; 

Restrictions 

The following are restrictions for encrypted tablespaces: 

■ You cannot encrypt an existing tablespace with an ALTER TABLESPACE statement. 
However, you can use Data Pump or SQL statements such as CREATE TABLE AS 
SELECT or ALTER TABLE MOVE to move existing table data into an encrypted 
tablespace. 

■ Encrypted tablespaces are subject to restrictions when transporting to another 
database. See "Limitations on Transportable Tablespace Llse" on page 12-32, 

■ When recovering a database with encrvpted tablespaces (for example after a 
SHUTDOWN ABORT or a catastrophic error that brings down the database instance), 
you must open the Oracle wallet after database mount and before database open, 
so the recovery process can decrypt data blocks and redo. 

In addition, see Oracle Dalahase Advanced Security Administrator's Guide for general 
Testrictions for transparent data encryption. 

Querying Tablespace Encryption Information 

The DBA_TABLE SPACES and USER_TABLESPACES data dictionary views include a 
column named ENCRYPTED. This column contains YES for encrvpted tablespaces. 

The view VSENCRYPTED_TABLESPACES lists all currently encrypted tablespaces. The 
following query displays the name and encryption algorithm of encrypted tablespaces: 

SELECT t.name, e.encryptianalg algorithm 

FROM vjtaiilespace t. vjencryptedjables paces e 
WHERE t.tsi = e.tstt; 

NME ALGORITHM 

SECURESPACE AES128 
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See Also: 



Orach' Database 1 Day + Security Guide for more information about 
transparent data encryption and for instructions for creating and 
opening wallets 

"Consider Encn'pting Columns That Contain Sensitive Data" on 
page 18-6 for an alternative to encrypting an entire tabtespace 

Oracle Real AppHcatioti Ctiisteis Administration and Deployment 
Guide for information on using an Oracle wallet in an Oracle Real 
Application Clusters environment 

Oracle Database SQL Language Reference for inform.ation about the 

CREATE TABLESPACE statement 



Temporary Tablespaces 



A lemporary tablespace contains transient data that persists onlv for the duration of 
the session. Temporarv tablespaces can improve the concurrency of multiple sort 
operations that do not fit in memory and can improve the efficiency of space 
management operations during sorts. 

Temporarv tablespaces are used to store the following: 

■ Intermediate sort results 

■ Temporarv tables and lem.porary indexes 

■ Temporarv LOBs 

■ Temporary B-tiees 

Within a temporary tablespace, all sort operations for a particular instance share a 
single sort segment, and sort segments exist for everv instance that performs sort 
operations that require temporarv space. A sort segment is created by the first 
statement after startup that uses the temporary tablespace for sorting, and is released 
onlv at shutdown. 

By default, a single temporary tablespace named TEMP is created for each new Oracle 
Database installation. You can create additional temporarv tablespaces with the 
CREATE TABLESPACE statement. You can assign a temporar}'- tablespace to each 
database user with the CREATE USER or ALTER USER statement. A single temporary 
tablespace can be shared by multiple users. 

You cannot explicitly create objects in a temporary tablespace. 

Note: The exception to the preceding statement is a temporary' table. 
When you create a temporarv table, its rows are stored in vour default 
temporary tablespace, unless you create the table in a new temporary 
tablespace. See "Creating a Temporary Table" on page 18-9 for more 
information. 



Default Temporary Tablespace 

Users who are not explicitly assigned a temporary tablespace use the database default 
temporary tablespace, which for new installations is TEMP. You can change the default 
temporarv tablespace for the database with the following command: 

ALTER DATABASE DEFAULT TEMPORARY TABLESPACE tdblespdce_name: 
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To determine the current default temporary tablespace for the database, run the 
following query: 

SEIECT PROPERIYJAHE. PROPEIRT¥_VALDE FROM DATABASEJROPERTIES WHERE 
PROPERT¥_NftME= ' DEFADLT_TEMP_TABLESPACE ' ; 

PROPERTY.MHE PROPERT¥_VM.UE 

DEFAULT TEMP TABLESPACE TEMP 



Space Allocation In a Temporary Tablespace 

You can view the allocation and deallocation of space in a temporan' tablespace sort 
segment using the VS30RT_3EGMENT view. The VSSORT_USAGE view identifies the 
current sort users in those segments. 

When a sort operation that uses temporan' space completes, allocated extents in the 
sort segment are not deallocated; thev are just marked as free and available for reuse. 
The DBA_TEMP_FREE_S PACE view displays the total allocated and free space in each 
lemporarv tablespace. See "Viewing Space Usage for Temporarv Tablespaces" on 
page 12-12 for more information. You can miinuallv shrink a locallv managed 
temporarv tablespace that has a large amount of unused space. See "Shrinking a 
Locallv Managed Temporal' Tablespace" on page 12-23 for details. 

See Also: 

■ Oracle Database Security Guide for information about creating 
users and assigning temporary tablespaces 

■ Oracle Database Concepts for more information about the default 
temporarv tablespace 

■ Oracle Database Reference for more information about the 

V$30RT_3EGMENT, V$30RT_U3AGE, and 
DBA_TEMP_FREE_3PACE views 

■ Oracle Database Performance Tuning Guide for a discussion on 
tuning sorts 

Creating a Locally Managed Temporary Tablespace 

Because space management is much simpler and more efficient in locallv managed 
tiible spaces, they are ideallv suited for temporarv tablespaces. Locally managed 
temporarv tablespaces use tempfiles, which do not modifv data outside of the 
temporarv tablespace or generate anv redo for temporarv tablespace data. Because of 
this, thev enable you to perform on-disk sorting operations in a read-onlv or standby 
database. 

You also use different views for viewing information about tempfiles than you would 
for datafiles. The VSTEMPFILE and DBA_TEMP_FILES views are analogous to the 

VSDATAFILE and DBA_DATA_FILES views. 

To create a locallv managed temporary tablespace, vou use the CREATE TEMPORARY 
TABLESPACE statement, which requires that you have the CREATE TABLESPACE 
system privilege. 

The following statement creates a temporary tablespace in which each extent is 16M. 
Each 16M extent (which is the equivalent of 8000 blocks when the standard block size 
is 2K) is represented by a bit in the bitmap for the file. 

CREATE TEMPORARY TABLESPACE Imtemp TEHPFILE 7u02/Dracle/data/lmtemp01.dl>f' 
SIZE 20M REnSE 
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EXTENT MMAGEHENT LOCAL miFORM SIZE 15M; 

The extent management clause is optional for temporary tablespaces because all 
temporarv tablespaces are created with locally managed extents of a uniform size. The 
default for SIZE is IM. But if you want to specify another value for SIZE, you can do 
so as shown in the preceding statement. 

Note: On some operating systems, the database does not allocate 
space for the tempfile until the tempfile blocks are actually 
accessed. This delay in space allocation results in faster creation 
and resizing of tempfiles, but it requires that sufficient disk space is 
available when the tempfiles are later used. Please refer to vour 
operating system documentation to determine whether the 
database allocates tempfile space in this way on your system. 

Creating a Bigfile Temporary Tablespace 

Just as for regular tablespaces, vou can create single-file (bigfile) temporair 
tablespaces. Use the CREATE BIGFILE TEMPORARY TABLESPACE statement to 
create a single- tempfile tablespace. See the sections "Creating a Bigfile Tablespace" on 
page 12-7 and "Altering a Bigfile Tablespace" on page 12-21 for information about 
bigfile tablespaces, but consider that you are creating temporary tablespaces that use 
tempfiles instead of datafiles. 

Viewing Space Usage for Temporary Tabiespaces 

The DBA_TEMP_FREE_SPACE dictionary view contains information about space usage 
for each temporar;' tablespace. The information includes the space allocated and the 
free space. You can query this view for these statistics using the following command. 

SELECT ' from DBA_TEMP_FREE_SPACEr 

TABLESPACE_NME TABLESPACE_SIZE ALLOCATED_S PACE FREE_SPACE 

TEMP 2 50609654 2 50609664 249561038 

Multiple Temporary Tablespaces: Using Tablespace Groups 

A lablespace group enables a user to consume temporary space from multiple 
tablespaces. Using a tablespace group, rather than a single temporary tablespace, can 
alleviate problems caused where one tablespace is inadequate to hold the results of a 
sort, particularly on a table that has many partitions, A tablespace group enables 
parallel execution ser\'ers in a single parallel operation to use multiple temporary 
tablespaces, 

A tablespace group has the foUowing characteristics; 

■ It contains at least one tablespace. There is no explicit limit on the maximum 
number of tablespaces that are contained in a group, 

■ It shares the namespace of tablespaces, so its name cannot be the same as anv 
tablespace, 

■ You can specify a tablespace group name wherever a tablespace name would 
appear when you assign a default temporarv tablespace for the database or a 
temporary tablespace for a user. 
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You do not explicitly create a tablespace group. Rather, it is created implicitly when 
you assign the first temporar}' tablespace to the group. The group is deleted when the 
last temporary tablespace it contains is removed from it. 

The view DBA_TABLESPACE_GROUPS hsts tablespace groups and their member 
tablespaces. 

See Also: Oracle Daiabase Security Guide for more information 
about assigning a temporary tablespace or tablespace group to a 



Creating a Tablespace Group 

You create a tablespace group implicitly when you include the TABLESPACE GROUP 
clause in the CREATE TEMPORARY TABLESPACE or ALTER TABLESPACE statement 
and the specified tablespace group does not currently exist. 

For example, if neither groupl nor group2 exists, then the following statements 
create those groups, each of which has only the specified tablespace as a member: 

CREATE TEMPORARY TABLESPACE lraterap2 TEMPFILE 7-u02/oracle/data/lintemp201 .dbf 
SIZE BOM 
TABLESPACE GROUP groupl; 

ALTER TABLESPACE Imtemp TABLESPACE GROUP group2; 

Changing Members of a Tablespace Group 

You can add a tablespace to an existing tablespace group by specifying the existing 
group name in the TABLESPACE GROUP clause of the CREATE TEMPORARY 

TABLESPACE or ALTER TABLESPACE statement. 

The following statement adds a tablespace to an existing group. It creates and adds 
tablespace lnitemp3 to groupl, so that groupl contains tablespaces lmtemp2 and 
Imtemp 3. 

CREATE TEMPORARY TABLESPACE lraterap3 TEMPFILE 7u02/oracle/data/lintemp301 .dbf 
SIZE 25M 
TABLESPACE GROUP groupl; 

The following statement also adds a tablespace to an existing group, but in this case 
because tablespace lmtemp2 already belongs to groupl, it is in effect moved from 

groupl to group2: 

ALTER TABLESPACE lmtemp2 TABLESPACE GROUP group 2 ; 

Now group2 contains both Imtemp and lmtemp2, while groupl consists of only 

tmtemp3. 

You can remove a tablespace from a group as shown in the following statement: 

ALTER TABLESPACE linterap3 TABLESPACE GROUP ' ; 

Tablespace lmtemp3 no longer belongs to any group. Further, since there are no 
longer any members of groupl, this results in the implicit deletion of groupl. 

Assigning a Tablespace Group as the Defauit Temporary Tabiespace 

Use the ALTER DATABASE. . .DEFAULT TEMPORARY TABLESPACE statement to 

assign a tablespace group as the default temporary tablespace for the database. For 
example: 
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ALTER DATABASE sample DEFAULT TEMPORARY TABLESPACE group2 ; 

Any user who has not expUcitIv been assigned a temporary tablespace will now use 
tablespaces Irnternp and lmtemp2. 

If a tablespace group is specified as the default temporary tablespace, you cannot drop 
anv of its member tablespaces. You must first remove the tablespace from the 
tablespace group. Likewise, vou cannot drop a single temporary tablespace as long as 
it is the default temporary tablespace. 

Specifying Nonstandard Block Sizes for Tablespaces 

You can create tablespaces with block sizes different from the standard database block 
size, which is specified bv the DB_BLOCK_SIZE initialization parameter. This feature 
lets vou transport tablespaces with unlike block sizes between databases. 

Use the BLOCKS I ZE clause of the CREATE TABLESPACE statement to create a 
tablespace with a block size different from the database standard block size. In order 
for theBLOCKSIZE clause to succeed, you must have already set the DB_CACHE_SIZE 
and at least one DB_nK_CACHE_SI ZE initialization parameter Further, and the 
integer you specify in the BLOCKSI ZE clause must correspond with the setting of one 
DB_nK_CACHE_SlZE parameter setting. Although redundant, specif}'ing a 
BLOCKSI ZE equal to the standard block size, as specif led by the DB_BLOCK_SIZE 
initialization parameter, is allowed. 

The following statement creates tablespace Imtbsb, but specifies a block size that 
differs from the standard database block size (as specified bv the DB_BLOCK_SIZE 
initializationparameter): 

CREATE TABLESPACE Imtbsb DATAFILE 7u02/oracle/data/lmtbEb01.dbf' SIZE 50M 
EXTENT MANAGEMENT LOCAL UHIFORM SIZE 128K 
BLOCKSIZE 8K; 

See Also: 

■ "Specifying Database Block Sizes" on page 2-27 

■ "Setting the Buffer Cache Initialization Parameters" on 
page 5-15 for information about the DB_CACHE_SIZE and 
DB_nK_CACHE_SIZE parameter settings 

■ "Transporting Tablespaces Between Databases" on page 12-29 

Controlling the Writing of Redo Records 

For some database operations, vou can control whether the database generates redo 
records. Without redo, no media recovery is possible. However, suppressing redo 
generation can improve performance, and may be appropriate for easily recoverable 
operations. An example of such an operation is a CREATE TABLE , , , AS SELECT 
statement, w^hich can be repeated in case of database or instance failure. 

Specify the NOLOGGIWG clause in the CREATE TABLESPACE statement if you wish to 
suppress redo when these operations are performed for objects within the tablespace. 
If you do not include this clause, or if you specify LOGGING instead, then the database 
generates redo when changes are made to objects in the tablespace. Redo is never 
generated for temporary segments or in temporary tablespaces, regardless of the 
logging attribute. 

The logging attribute specified at the tablespace level is the default attribute for objects 
created w^ithin the tablespace. You can override this default logging attribute by 
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specifying LOGGING or NOLOGGING at the schema object level— for example, in a 

CREATE TABLE statement. 

If you have a standby database, NOLOGGING mode causes problems with the 
availability and accuracy of the standbv database. To overcome this problem, vou can 
specify FORCE LOGGING mode. When you include the FORCE LOGGING clause in the 
CREATE TABLESPACE statement, you force the generation of redo records for all 
operations that make changes to objects in a tablespace. This overrides anv 
specification made at the object level. 

If you transport a tablespace that is in FORCE LOGGING mode to iinother database, the 
new tablespace will not maintain the FORCE LOGGING mode. 

See Also: 

■ Oracle Database SQL Lairguagc Reference for information about 
operations that can be done in NOLOGGING mode 

■ "Specifying FORCE LOGGING Mode" on page 2-22 for more 
information about FORCE LOGGING mode and for information 
about the effects of the FORCE LOGGING clause used with the 

CREATE DATABASE statement 
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You can take an online tablespace offline so that it is temporarily unavailable for 
general use. The rest of the database remains open and available for users to access 
data. Conversely vou can bring an offhne tablespace online to make the schema 
objects within the tablespace available to database users. The database must be open to 
alter the availabilitv of a tablespace. 

To alter the availability of a tablespace, use the ALTER TABLESPACE statement. You 
must have the ALTER TABLESPACE or MANAGE TABLESPACE system privilege. 

See Also: "Altering Datafile Availabilitv" on page 13-6 for 
information about altering the availabUity of individual datafiles 
within a tablespace 

Taking Tablespaces Offline 

You may want to take a tablespace offline for anv of the following reasons: 

■ To make a portion of the database unavailable while allowing normal access to the 
remainder of the database 

■ To perform an offline tablespace backup (even though a tablespace can be backed 
up while online and in use) 

■ To make an application and its group of tables temporarily unavailable w^hile 
updating or maintaining the application 

■ To rename or relocate tablespace datafiles 

See "Renaming and Relocating Datafiles" on page 13-8 for details. 
When a tablespace is taken offline, the database takes all the associated files offline. 
You cannot take the following tablespaces offline: 

■ SYSTEM 

■ The undo tablespace 
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■ Temporarv tablespaces 

Before taking a tablespace offline, consider altering the tablespace allocation of any 
users who have been assigned the tablespace as a default tablespace. Doing so is 
advisable because those users will not be able to access objects in the tablespace while 
it is offline. 

You can specifv any of the following parameters as part of the ALTER 

TABLESPACE. . .OFFLINE statement; 



Clause 



Description 



NORMAL 



TEMPORARY 



A tablespace can be taken offline normally if no error conditions 
exist for any of the datafiles of the tablespace. No datafile in the 
tablespace can be currently offline as the result of a write error 
When you specify OFFLIHE HOEMAL, the database takes a 
checkpoint for all datafiles of the tablespace as it takes them 
offline. HORMAL is the default. 

A tablespace can be taken offline temporarily, even if there are 
error conditions for one or more files of the tablespace. When 
you specify OFFLIHE TEMPORARY, the database takes offline 
the datafiles that are not already offline, checkpointing them as 
it does so. 

If no files are offline, but you use the temporary clause, media 
recovery is not required to bring the tablespace back online. 
However, if one or more files of the tablespace are offline 
because of write errors, and you take the tablespace offline 
temporarily, the tablespace requires recovery before you can 
brine itback online. 



IMMEDIATE 



A tablespace can be taken offline immediately, without the 
database taking a checkpoint on any of the datafiles. When you 
specify OFFLINE IMMEDIATE, media recovery for the 
tablespace is required before the tablespace can be brought 
online. You cannot take a tablespace offline immediately if the 
database is running in HOARCHIVELOG mode. 



Caution: If you must take a tablespace offline, use the NORMAL 
clause (the default) if possible. This setting guarantees that the 
tablespace will not require recovery to come back online, even if 
after incomplete recovery you reset the redo log sequence using an 

ALTER DATABASE OPEN RESETLOGS statement. 



Specify TEMPORARY only when vou cannot take the tablespace offline normallv. In this 
case, onlv the files taken offline because of errors need to be recovered before the 
tablespace can be brought online. Specifv IMMEDIATE only after trying both the 
normal and temporary settings. 

The following example takes the users tablespace offline normally: 

ALTER TABLESPACE users OFFLINE HORMAL; 



Bringing Tablespaces Online 



You can bring any tablespace in an Oracle Database online whenever the database is 
open. A tablespace is normally online so that the data contained within it is available 
to database users. 
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If a tablespace to he brought online was not taken offline "cleanlv" (tliat is, using tlie 
NORMAL clause of the ALTER TABLESPACE OFFLINE statement), you must first 
perform media recovery on the tablespace before bringing it online. Otherwise, the 
database returns an error and the tablespace remains offline. 

See Also: Oracle DiifabiKC Backup and Recovery User's Guide for 
information about performing media recovery 

The following statement brings the users tablespace online: 

ALTEK TABLESPACE users OILIHE; 



Using Read-Only Tablespaces 



Making a tablespace read-only prevents write operations on the datafiles in the 
tablespace. The priman' purpose of read-only tablespaces is to eliminate the need to 
perform backup and recoverv of large, static portions of a database. Read-only 
tablespaces also provide a wav to protecting historical data so that users cannot 
m.odify it. Making a tablespace read-onlv prevents updates on all tables in the 
tablespace, regardless of a user's update privilege level. 

Note: Making a tablespace read-only cannot in itself be used to 
satisfy archiving or data publishing requirements, because the 
tablespace can only be brought online in the database in which it 
was created. However, vou can meet such requirements by using 
the transportable tablespace feature, as described in "Transporting 
Tablespaces Between Databases " on page 12-29. 



You can drop items, such as tables or indexes, from a read-only tablespace, but you 
cannot create or alter objects in a read-onlv tablespace. You can execute statements 
that update the file description in the data dictionary, such as ALTER TABLE . . .ADD 
or ALTER TABLE . . .MODIFY, but VOU will not be able to utilize the new description 
until the tablespace is made read/write, 

Read-onlv tablespaces can be transported to other databases. And, since read-only 
tablespaces can never be updated, they can reside on CD-ROM or WORM (Write 
Once-Read Many) devices. 

The following topics are discussed in this section: 

■ Making a Tablespace Read-Onlv 

■ Making a Read-Only Tablespace Writable 

■ Creating a Read-Only Tablespace on a WORM Device 

■ Delaying the Opening of Datafiles in Read-Only Tablespaces 

See Also: "Transporting Tablespaces Between Databases" on 
page 12-29 



Making a Tablespace Read-Only 



All tablespaces are initially created as read/write. Use the READ ONLY clause in the 
ALTER TABLESPACE statement to change a tablespace to read-only. You must have 
theALTER TABLESPACE or MANAGE TABLESPACE system privilege. 

Before vou can make a tablespace read-only, the following conditions must be met. 
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■ The tablespace must be onlme. This is necessary to ensure that there is no undo 
information that needs to be applied to the tablespace. 

■ The tablespace cannot be the active undo tablespace or SYSTEM tablespace. 

■ The tablespace must not currently be involved in an online backup, because the 
end of a backup updates the header file of all datafiles in the tablespace. 

For better performance while accessing data in a read-only tablespace, you can issue a 
query that accesses all of the blocks of the tables in the tablespace just before making it 
read-onlv. A simple query, such as SELECT COUNT (* ) , executed against each table 
ensures that the data blocks in the tablespace can be subsequentlv accessed most 
efficiently. This eliminates the need for the database to check the status of the 
transactions that most recently modified the blocks. 

The following statement makes the flights tablespace read-only: 

ALTER TABLESPACE flights READ OHLY; 

You can issue the ALTER TABLESPACE. . .READ ONLY statement while the database 
is processing transactions. After the statement is issued, the tablespace is put into a 
transitional read-onlv state. No transactions are allowed to make further changes 
(using DML statements) to the tablespace. If a transaction attempts further changes, it 
is terminated and rolled back. However, transactions that already made changes and 
that attempt no further changes are allowed to commit or roll back. 

When there are transactions waiting to commit, the ALTER TABLESPACE . . . READ 
ONLY statement does not return immediately. It waits for all transactions started 
before you issued the ALTER TABLESPACE statement — even transactions that are 
against objects in different tablespaces — to either commit or roll back. 



Note: This transitional read-only state only occurs if the value of 
the initialization parameter COMPATIBLE is 8.1.0 or greater If this 
parameter is set to a value less than 8.1.0, the ALTER 
TABLESPACE. . .READ ONLY statement fails if any active 
transactions exist. 



If you find it is taking a long time for the ALTER TABLESPACE statement to complete, 
you can identify the transactions that are preventing the read-only state from taking 
effect. You can then notifv the owners of those transactions and decide whether to 
terminate the transactions, if necessarv. 

The following example identifies the transaction entry for the ALTER 
TABLESPACE. . .READ ONLY statement and displays its session address (saddr): 

SELECT SQL_TEXT, SADDR 

FROM VSSQLAREA,VSSES3I0H 

WHERE VSSQLAREA. ADDRESS = V$SESSIOH.SQL_ADDRESS 
AND SQL_TEXT LIKE 'alter tablespace% ' ; 

SQL_TEXT SADDR 

alter tablespace tbsl read only 80034AF0 

The start SCN of each active transaction is stored in the VSTRANSACTION view. 
Displaying this view sorted by ascending start SCN lists the transactions in execution 
order From the preceding example, you already know the session address of the 
transaction entry for the read-only statement, and you can now locate it in the 
V$ TRANSACTION view. All transactions with smaller start SCN, which indicates an 
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800352AO 


3621 


80035A50 


3623 


80034AFO 


3628 


80037910 


3629 



earlier execution, can potentially hold up the quiesce and subsequent read-only state 
of the tablespace. 

SELECT SES_ADDR, 3TART_SCNB 
FROM VSTRMSACTIOH 
ORDER BY 3TART_SCNB; 

SE3_ADDR 3TART_SCNB 

--> waiting on this t:xn 

--> waiting on this t:xn 

--> this is the ALTER TABLESPACE statement 

--> don't care about this txn 

You can now find the owners of the blocking transactions. 

SELECT T.3ES_ADDR, S.USERHAME, S .MftCHIHE 
FROM VS3ES3IOH S, VSTRAHSACTION T 
INHERE T.SE3_ADDR = S.SADDR 
ORDER BY T.SES_ADDR 

SES_ADDR USERMAME MACHIHE 

800352AO DAVIDB DAVIDBLAP — > Contact this user 

80035A50 MIKEL LAB61 — > Contact this user 

80034AFO DBAOl STEVEFLAP 

80037910 HICKD HICKDLAP 

After making the tablespace read-onlv, it is advisable to back it up immediately. As 
long as the tablespace remains read-only, no further backups of the tablespace are 
necessary, because no changes can be made to it. 

See Also: Oracle Database Backup and Recovery User's Guide 



Making a Read-Only Tablespace Writable 

Use the READ WRITE keywords in the ALTER TABLESPACE statement to change a 
tablespace to allow write operations. You must have the ALTER TABLESPACE or 
MANAGE TABLESPACE system privilege, 

A prerequisite to making the tablespace read/write is that all of the datafiles in the 
tablespace, as well as the tablespace itself, must be online. Use the 

DATAFILE . . . ONLINE clause of the ALTER DATABASE statement to bring a datafile 
online. The VSDATAFILE view lists the current status of datafiles. 

The following statement makes the flights tablespace writable: 

ALTER TABLESPACE flights READ IVRITE; 

Making a read-only tablespace writable updates the control file entrv for the datafiles, 
so that you can use the read-only version of the datafiles as a starting point for 
recovery. 

Creating a Read-Only Tablespace on a WORM Device 

Follow these steps to create a read-onJy tablespace on a CD-ROM or WORM (Write 
Once-Read Many) device, 

1. Create a writable tablespace on another device. Create the objects that belong in 
the tablespace and insert your data. 
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2. Alter the tablespace to make it read-onlv. 

3. Copy the datafiles of the tablespace onto the WORM device. Use opierating system 
comm.ands to copy the files, 

4. Take the tablespace offline, 

5. Rename the datafiles to coincide with the names of the datafiles you copied onto 

your WORM device. Use ALTER TABLESPACE with the RENAME DATAFILE 
clause. Renaming the datafiles changes their names in the control file. 

6. Bring the tablespace back online. 

Delaying the Opening of Datafiles in Read-Only Tablespaces 

When substantial portions of a very large database are stored in read-only tablespaces 
that are located on slow-access devices or hierarchical storage, vou should consider 
setting the READ_ONLY_OPEN_DELAYED initialization parameter to TRUE. This speeds 
certain operations, primarily opening the database, bv causing datafiles in read-only 
tablespaces to be accessed for the first time only when an attempt is made to read data 
stored within them. 

Setting READ_ONLY_OPEN_DELAYED=TRUE has the following side-effects: 

■ A missing or bad read-only file is not detected at open time. It is only discovered 
when there is an attempt to access it, 

■ ALTER SYSTEM CHECK DATAFILES does not check read-only files, 

■ ALTER TABLESPACE. . .ONLINE andALTER DATABASE DATAFILE ... ONLINE 

do not check read-only files. They are checked only upon the first access. 

■ VSRECOVER_FILE, VSBACKUP, and V$DATAFILE_HEADER do not access 

read-only files. Read-only files are indicated in the results list with the error 
"delayed open", vifith zeroes for the values of other columns, 

■ V$DATAFILE does not access read-only files, Read-onlv files have a size of "0" 
listed, 

■ V$REC0VER_LOG does not access read-only files. Logs they could need for 
recovery are not added to the list, 

■ ALTER DATABASE NOARCHIVELOG does not access read-only files, It proceeds 
even if there is a read-only file that requires recovery. 



Notes: 



RECOVER DATABASE andALTER DATABASE OPEN 

RESETLOGS continue to access all read-only datafiles 
regardless of the parameter value. If you want to avoid 
accessing read-only files for these operations, those files should 
be taken offline. 

If a backup control file is used, the read-onlv status of some 
files may be inaccurate. This can cause some of these operations 
to return unexpected results. Care should be taken in this 
situation. 
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Altering and Maintaining Tablespaces 

This section covers various subjects that relate to altering and maintaining tablespaces. 
Included are the following topics: 

■ Altering a Locally Managed Tablespace 

■ Altering a Bigfile Tablespace 

■ Altering a Locally Managed Temporary Tablespace 

■ Shrinking a Locally Managed Temporary Tablespace 

Altering a Locally Managed Tablespace 

You cannot alter a locally managed tablespace to a locally managed temporary 
tablespace, nor can you change its method of segment space management Coalescing 
free extents is unnecessary for locally managed tablespaces. However, you can use the 
ALTER TABLESPACE statement on locally managed tablespaces for some operations, 
including the following: 

■ Adding a datafile. For example: 

ALTEE TABLESPACE Imtbsb 

ADD DATfiFILE 7u02/oracle/data/lmtbsb02 .dbf SIZE IM; 

■ Altering tablespace availabiUty (ONLINE/OFFLINE). See "Altering Tablespace 
Availabilit\'" on page 12-15. 

■ Making a tablespace read-only or read/write. See "Using Read-Only Tablespaces" 
on page 12-17. 

■ Renaming a datafile, or enabling or disabling the autoextension of the size of a 
datafile in the tablespace. See Chapter 13, "Managing Datafiles and Tempfiles". 



Altering a Bigfile Tablespace 



Two clauses of the ALTER TABLESPACE statement support datafile transparency 
wfhen you are using bigfile tablespaces: 

■ RESIZE: The RESIZE clause lets you resize the single datafile in a bigfile 
tablespace to an absolute size, without referring to the datafile. For example: 

ALTER TABLESPACE bigtbs RESIZE BOG; 

■ AUTOEXTEWD (used outside of the ADD DATAFILE clause): 

With a bigfile tablespace, you can use the AUTOEXTEWD clause outside of the ADD 
DATAPILE clause. For extimple: 

ALTER TABLESPACE bigtbs AUTOEXTEND OH HEXT 20G; 

An error is raised if you specify an ADD DATAFILE clause for a bigfile tablespace. 
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Altering a Locally Managed Temporary Tablespace 



Note: You cannot use the ALTER TABLESPACE statement, with 
the TEMPORARY keyword, to change a locally managed permanent 
tablespace into a locally managed temporary tablespace. You must 
use the CREATE TEMPORARY TABLESPACE statement to create a 
locally managed temporary tablespace. 



You can use ALTER TABLESPACE to add a tempfile, take a tempfile offline, or bring a 
tempfile online, as illustrated in the following examples; 

ALTER TABLESPACE Imterap 

ADD TEMPFILE ' /u02/oracle/data/lmtemp02 .dbf SIZE IBM REUSE; 

ALTER TABLESPACE Imterap TEMPFILE OFFLIHE; 
ALTER TABLESPACE Imterap TEMPFILE ONLINE; 



Note: You cannot take a temporary tablespace offline. Instead, you 
take its tempfile offline. The view VSTEMPFILE displavs online status 
for a tempfile. 



The ALTER DATABASE statement can be used to alter tempfiles. 

The following statements take offline and bring online tempfiles. They behave 
identicaUy to the last two ALTER TABLESPACE statements in the previous example. 

ALTER DATABASE TEMPFILE ' /u02/oracle/data/lmtemp02 .dbf OFFLIHE; 
ALTER DATABASE TEMPFILE ' /u02/oracle/data/lmtemp02 .dbf ' ONLINE; 

The following statement resizes a tempfile: 

ALTER DATABASE TEMPFILE ' /u02/oracle/data/lmtemp02 ,dbf' RESIZE 18M; 

The following statement drops a tempfile and deletes its operating system file: 

ALTER DATABASE TEMPFILE ' /u02/oracle/data/lmtemp02 ,dbf DROP 
INCLUDING DATAFILES; 

The tablespace to which this tempfile belonged remains, A message is written to the 
alert log for the tempfile that was deleted. If an operating system error pre\'ents the 
deletion of the file, the statement still succeeds, but a message describing the error is 
written to the alert log. 

It is also possible to use the ALTER DATABASE statement to enable or disable the 
automatic extension of an existing tempfile, and to rename (RENAME FILE) a tempfile. 
See Oracle Database SQL Language Reference for the required syntax. 

Note: To rename a tempfile, you take the tempfile offline, use 
operating system commands to rename or relocate the tempfile, and 
then use the ALTER DATABASE RENAME FILE command to update the 
database controlfiles. 
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Shrinking a Locally Managed Temporary Tablespace 

Large sort operations performed by the database may result in a temporary tablespace 
growing and occupying a considerable amount of disk space. After the sort operation 
completes, the extra space is not released; it is just marked as free and available for 
reuse. Therefore, a single large sort operation might result in a large amount of 
allocated temporary space that remains unused after the sort operation is complete. 
For this reason, the database enables you to shrink locally managed temporary 
tablespaces and release unused space. 

Youuse the SHRINK SPACE clause of the ALTER TABLESPACE statement to shrink a 
lemporan,' tablespace, or the SHRINK TEMPFILE clause of the ALTER TABLESPACE 
statement to shrink a specific tempfile of a temporary tablespace. Shrinking frees as 
much space as possible while maintaining the other attributes of the tablespace or 
tempfile. The optional KEEP clause defines a minimum size for the tablespace or 
tempfile. 

Shrinking is an online operation, which means that user sessions can continue to 
allocate sort extents if needed, and already-running queries are not affected. 

The following example shrinks the locally managed temporary tablespace Imtmpl to a 
size of 20M, 

ALTER TABLESPACE Imtempl SHRINK SPACE KEEP 20H; 

The following example shrinks the tempfile Im temp 2 . dbf of the locally managed 
temporary tablespace lmtmp2. Because the KEEP clause is omitted, the database 
attempts to shrink the tempfUe to the minimum possible size, 

ALTER TABLESPACE lmterap2 SHRINK TEMPFILE 7u02/oracle/data/ljnterap02 .dbf ; 



Renaming Tablespaces 



Using the RENAME TO clause of the ALTER TABLESPACE, you can rename a 
permanent or temporary tablespace. For example, the following statement renames the 
users tablespace: 

ALTER TABLESPACE users RENAME TO usersts; 

When you rename a tablespace the database updates all references to the tablespace 
name in the data dictionary, control file, and (online) datafile headers. The database 
does not change the tablespace ID so if this tablespace were, for example, the default 

ablespace for a user, then the renamed tablespace would show as the default 

ablespace for the user in the DBA_USERS yiew. 

The following affect the operation of this statement; 

The COMPATIBLE parameter must be set to 10,0,0 or higher. 

If the tablespace being renamed is the SYSTEM tablespace or the SYSAUX 
tablespace, then it will not be renamed and an error is raised. 

If any datafile in the tablespace is offline, or if the tablespace is offline, then the 
tablespace is not renamed and an error is raised. 

If the tablespace is read only, then datafile headers are not updated. This should 
not be regarded as corruption; instead, it causes a message to be written to the 
alert log indicating that datafile headers have not been renamed. The data 
dictionary and control file are updated. 
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If the tablespace is the default temporarv tablespace, then the corresponding entry 
in the database properties table is updated and the DATABASE_PROPERTIES view 
shows the new name. 

If the tablespace is an undo tablespace and if the following conditions are met, 
then the tablespace name is changed to the new tablespace name in the server 
parameter file (SPFILE). 

- The server parameter file was used to start up the database. 

- The tablespace name is specified as the UNDO_TABLE SPACE for any instance. 

If a traditional initialization parameter file (PFILE) is being used then a message is 
written to the alert log stating that the initialization parameter file must be 
manually changed. 



Dropping Tablespaces 



You can drop a tablespace and its contents (the segments contained in the tablespace) 
from the database if the tablespace and its contents are no longer required. You must 
have the DROP TABLESPACE system privilege to drop a tablespace. 

Caution: Once a tablespace has been dropped, the data in the 
tablespace is not recoverable. Therefore, make sure that all data 
contained in a tablespace to be dropped will not be required in the 
future. Also, immediately before and after dropping a tablespace 
from a database, back up the database completely. This is strongly 
recommended so that you can recover the database if vou mistakenly 
drop a tablespace, or if the database experiences a problem in the 
future after the tablespace has been dropped. 



When you drop a tablespace, the file pointers in the control file of the associated 
database are removed. You can optionally direct Oracle Database to delete the 
operating system files (dataf iles) that constituted the dropped tablespace. If you do not 
direct the database to delete the datafiles at the same time that it deletes the tablespace, 
you must later use the appropriate commands of your operating system to delete 
them. 

You cannot drop a tablespace that contains any active segments. For example, if a table 
in the tablespace is currently being used or the tablespace contains undo data needed 
to roll back uncommitted transactions, you cannot drop the tablespace. The tablespace 
can be online or offline, but it is best to take the tablespace offline before dropping it. 

To drop a tablespace, use the DROP TABLESPACE statement. The following statement 
drops the users tablespace, including the segments in the tablespace: 

DROP TABLESPACE users IHCLUDIHG C0HTEHT3; 

If the tablespace is empty (does not contain any tables, views, or other structures), you 
do not need to specify the INCLUDING CONTENTS clause. Use the CASCADE 
CONSTRAINTS clause to drop all referential integrity constraints from tables outside 
the tablespace that refer to primary and unique ke}'s of tables inside the tablespace. 

To delete the datafiles associated with a tablespace at the same time that the tablespace 
is dropped, use the INCLUDING CONTENTS AND DATAFILES clause. The following 
statement drops the users tablespace and its associated datafiles: 

DROP TABLESPACE users IHCLDDIHG CONTENTS AND DATAFILES; 
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A message is written to the alert log for each datafile that is deleted. If an operating 
system error prevents the deletion of a file, the DROP TABLESPACE statement still 
succeeds, but a message describing the error is written to the alert log. 



See Also: "Dropping Datafiles" on page 13-11 



Managing the SYSAUX Tablespace 

The SYSAUX tablespace was installed as an auxiUary tablespace to the SYSTEM 
tablespace when you created your database. Some database components that formerly 
created and used separate tablespaces now occupy the SYSAUX tablespace. 

If the SYSAUX tablespace becomes unavailable, core database functionality' will rem.aiii 
operational. The database features that use the SYSAUX tablespace could fail, or 
function with limited capabilit\'. 

Monitoring Occupants of the SYSAUX Tablespace 

The list of registered occupants of the SYSAUX tablespace are discussed in "About the 
SYSAUX Tablespace" on page 2-16. These components can use the SYSAUX tablespace, 
and their installation provides the means of establishing their occupancy of the 
SYSAUX tablespace. 

You can monitor the occupants of the SYSAUX tablespace using the 
VSSYSAUX_OCCUPANTS view. This view lists the following information about the 
occupants of the SYSAUX tablespace: 

■ Name of the occupant 

■ Occupant description 

■ Schema name 

■ Move procedure 

■ Current space usage 

View information is maintained by the occupants. 

See Also: Oracle Dalabasf Reference for a detailed description of 
the VSSYSAUX_OCCUPANTS view 

Moving Occupants Out Of or Into the SYSAUX Tablespace 

You wUl have an option at component instaU time to specify that you do not want the 
component to reside in SYSAUX. Also, if you later decide that the component should 
be relocated to a designated tablespace, you can use the move procedure for that 
component, as specified in the VSSYSAUX_OCCUP ANTS view, to perform the move. 

For example, assume that you instaU Oracle Ultra Search into the default tablespace, 
which is SYSAUX. Later you discover that Ultra Search is using up too much space. To 
alleviate this space pressure on SYSAUX, you can call a PL/SQL move procedure 
specified in the VSSYSAUX_OCCUPANTS view to relocate Ultra Search to another 
tablespace. 

The move procedure also lets you move a component from another tablespace into the 
SYSAUX tablespace. 
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Controlling the Size of the SYSAUX Tablespace 

The SYSAUX tablespace is occupied bv a number of database components (see 
Table 2-2), and its total size is governed bv the space consumed by those components. 
The space consumed by the components, in turn, depends on which features or 
functionahty are being used and on the nature of the database workload. 

The largest portion of the SYSADX tablespace is occupied by the Automatic Workload 
Repository' (AWR), The space consumed bv the AWR is determined bv several factors, 
including the number of active sessions in the system at anv given time, the snapshot 
interval, and the historical data retention period. A typical system with an average of 
30 concurrent active sessions mav require approximately 200 to 300 MB of space for its 
AWR data. You can control the size of the AWR by changing the snapshot interval and 
historical data retention period. For more information on managing the AWR 
snapshot interval and retention period, please refer to Oracle Database Performance 
Tuning Guide. 

Another major occupant of the SYSAUX tablespace is the embedded Enterprise 
Manager (EM) repositorv. This repository is used by Oracle Enterprise Manager 
Database Control to store its metadata. The size of this repository depends on database 
activity and on configuration-related information stored in the repository. 

Other database components in the SYSAUX tablespace will grow in size only if their 
associated features (for example, Oracle UltraSearch, Oracle Text, Oracle Streams) are 
in use. If the features are not used, then these components do not have anv significant 
effect on the size of the SYSAUX tablespace. 

Diagnosing and Repairing Locally Managed Tablespace Problems 

Oracle Database includes the DBMS_SPACE_ADMIN package, which is a collection of 
aids for diagnosing and repairing problems in locally managed tablespaces. 

DBMS_SPACE_ADMIN Package Procedures 

The following table lists the DBMS_SPACE_ADMIN package procedures. See Oracle 
Database PL/SQL Packages and Types Reference for details on each procedure. 



Procedure 



Description 



ASSM SEGMENT VERIFY 



Verifies the integrity of segments created in tablespaces that have 

automatic segment space management enabled. Outputs a dump file 
named s id_OT3._process_ld. trc to the location that corresponds 
to the Diag Trace entry in the VSDIAG_IKFO view. 

Use SEGMENT_VERIFY for tablespaces with manual segment space 
management. 



ASSM TABLESPACE VERIFY 



Verifies the integrity of tablespaces that have automatic segment 
space management enabled. Outputs a dump file named 

sid_ora_p2rocess_id. trc to the location that corresponds to the 
Diag Trace entry in the VSDIAG_INFO view. 

Use TABLES PACE_VERIFY for tablespaces with manual segment 
space management. 



SEGMENT CORRUPT 



Marks the segment corrupt or valid so that appropriate error recovery 

can be done 



SEGMENT DROP CORRUPT 



Drops a segment currently marked corrupt (without reclaiming space) 
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Procedure 



Description 



SEGMEHT DDMP 



SEGMEMT VERIFY 



Dumps the segment header and bitmap blocks of a specific segment to 
a dump file named sid_ora_pi"ocess_id,trc in the location that 
corresponds to the Diag Trace entry in the VSDIAGJNEO view. 
Provides an option (o select a slightly abbreviated dump, which 
includes segment header and includes bitmap block summaries, 
without percent-free states of each block. 

Verifies the consistency of the extent map of the segment 



TABLESPACE FIX BITMAPS 



Marks the appropriate DBA range (extent) as free or used in bitmap 



TABLESPACE FIX SEGMEHT STATES 



Fixes the state of the segments in a tabiespace in which migration was 

stopped 



TABLESPACE MIGRATE FROM LOCAL 



Migrates a locally managed tabiespace to dictionary-managed 
tabiespace 



TABLESPACE MIGRATE TO LOCAL 



Migrates a dictionary-managed tabiespace to a locally managed 
tabiespace 



TABLES PACE_REBUILD_BITMAPS 
TABLES PACE_REBUILD_QUOTAS 



Rebuilds the appropriate bitmaps 
Rebuilds quotas for a specific tabiespace 



TABLESPACE RELOCATE BITMAPS 



Relocates the bitmaps to the specified destination 



TABLESPACE VERIFY 



Verifies that the bitmaps and extent maps for the segments in the 
tabiespace are synchronized 



The following scenarios describe U'pical situations in which vou can use the 

DBMS_SPACE_ADMIN package to diagnose and resolve problems. 

Note: Some of these procedures can result in lost and 
unrecoverable data if not used properlv. You should work with 
Oracle Support Services if you have doubts about these procedures. 



See Also: 

■ Omclc Database PL/SQL Packages and T\ipes Reference for details 
about the DBMS_SPACE_ADMIW package 

"Viewing ADR Locations with the V$DIAG_INFO View" on 
page 8-8 

Scenario 1: Fixing Bitmap Wiien Allocated Blocks are Marlted Free (No Overlap) 

The TABLESPACE_VERIFY procedure discovers that a segment has allocated blocks 
that are marked free in the bitmap, but no overlap between segments is reported. 

In this scenario, perform the following tasks: 

1. Call the SEGMENT_DUMP procedure to dump the ranges that the administrator 
allocated to the segment, 

2. For each range, call the TABLESPACE_FIX_BITMAPS procedure with the 
TABLESPACE_EXTEWT_MAKE_USED option to mark the space as used, 

3. Call TABLESPACE_REBUILD_QUOTAS to rebuUd quotas. 
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Scenario 2: Dropping a Corrupted Segment 

You cannot drop a segment because the bitmap has segment blocks marked "free". The 
system has automatically marked the segment corrupted. 

In this scenario, perform the following tasks; 

1. Call the SEGMENT_VERIFY procedure with the 
SEGMENT_VERIFY_EXTENTS_GLOBAL option. If no overlaps are reported, then 
proceed with steps 2 through 5. 

2. Call the SEGMENT_DUMP procedure to dump the DBA ranges allocated to the 
segment. 

3. For each range, call TABLE SPACE_FIX_BITMAPS with the 
TABLESPACE_EXTENT_MAKE_FREE option to mark the space as free, 

4. Call SEGMENT_DROP_CORRUPT to drop the SEGS entry. 

5. Call TABLESPACE_REBUILD_QUOTAS to rebuild quotas. 

Scenario 3: Fixing Bitmap Where Overlap is Reported 

The TABLESPACE_VERIFY procedure reports some overlapping. Some of the real data 
must be sacrificed based on previous internal errors. 

After choosing the object to be sacrificed, in this case say, table 1 1, perform the 
following tasks: 

1. Make a list of all objects that tl overlaps. 

2. Drop table tl. If necessary, follow up by calling the SEGMENT_DROP_CORRUPT 
procedure. 

3. Call the SEGMEHT_VERIFY procedure on all objects that tl overlapped. If 
necessary, call the TABLE SPACE_FIX_BITMAPS procedure to mark appropriate 
bitmap blocks as used. 

4. Rerun the TABLE SPACE_VERI FY procedure to verify that the problem is resolved. 

Scenario 4: Correcting lUledia Corruption of Bitmap Blocks 

A set of bitmap blocks has media corruption. 
In this scenario, perform the following tasks: 

1. Call the TABLE SPACE_REBUILD_BITMAPS procedure, either on all bitmap blocks, 
or on a single block if onlv one is corrupt. 

2. Call the TABLESPACE_REBUILD_QUOTAS procedure to rebuild quotas. 

3. Call the TABLESPACE_VERIFY procedure to verify that the bitmaps are 
consistent. 

Scenario 5: lUligrating from a Dictionary-Managed to a Locally Managed Tablespace 

Use the TABLBSPACE_MIGRATE_TO_LOCAL procedure to migrate a 
dictionary-managed tablespace to a locally managed tablespace. This operation is 
done online, but space management operations are blocked until the migration has 
been completed. This means that you can read or modify data while the migration is in 
progress, but if you are loading a large amount of data that requires the allocation of 
additional extents, then the operation may be blocked. 
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Assume that the database block size is 2K and the existing extent sizes in tablespiice 
tbs_l are 10, 50, and 10,000 blocks (used, used, and free). The MINIMUM EXTENT 
value is 20K (10 blocks). Allow the system to choose the bitmap allocation unit. The 
value of 10 blocks is chosen, because it is the highest common denominator and does 

not exceed MINIMUM EXTENT. 

The statement to convert tbs_l to a locally managed tablespace is as follows: 

EKEC DBMS_SP6CE_ADMIH.TABLESPACE_MIGRATE_T0_LOCAL { ' tbs_l ' } ; 

If vou choose to specify an aUocation unit size, it must be a factor of the unit size 
calculated bv the system. 

Migrating the SYSTEM Tablespace to a Locally Managed Tablespace 

Use the DBMS_SPACE_ADMIN package to migrate the SYSTEM tablespace from 
dictionarv-managed to locallv managed. The following statement performs the 
migration: 

SQh> EXECUTE DBHS_SPACE_ADMIM.TflBLESPACE_MIGRATE_TO_LOCAL{ 'SYSTEM' ) ; 

Before performing the migration the following conditions must be met: 

■ The database has a default temporary tablespace that is not SYSTEM . 

■ There are no rollback segments in the dictionarv-managed tablespace. 

■ There is at least one online rollback segment in a locally managed tablespace, or if 
using automatic undo management, an undo tablespace is online. 

■ All tablespaces other than the tablespace containing the undo space (that is, the 
tablespace containing the rollback segment or the undo tablespace) are in 
read-onlv mode. 

■ The system is in restricted mode, 

■ There is a cold backup of the database. 

All of these conditions, except for the cold backup, are enforced bv the 

TABLESPACE_MIGEATE_TO_LOCAL procedure. 



Note: After the SYSTEM tablespace is migrated to locally 
managed, any dictionary-managed tablespaces in the database 
cannot be made read/write. If you want to be able to use the 
dictionar\'-managed tablespaces in read/write mode, then Oracle 
recommends that you first migrate these tablespaces to locally 
managed before migrating the SYSTEM tablespace. 

Transporting Tablespaces Between Databases 

This section describes how to transport tablespaces between databases, and contains 
the following topics: 

Introduction to Transportable Tablespaces 

About Transporting Tablespaces Across Platforms 

Limitations on Transportable Tablespace Use 

Compatibility Considerations for Transportable Tablespaces 

Transporting Tablespaces Between Databases: A Procedure and Example 
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Using Transportable Tablespaces: Scenarios 



Note: You must be using the Enterprise Edition of OracleS/ or 
later to generate a transportable tablespace set. However, vou can 
use any edition of OracleS/ or later to import a transportable 
tablespace set into an Oracle Database on the same platform. To 
import a transportable tablespace set into an Oracle Database on a 
different platform, both databases must have compatibilit;' set to at 
least 10.0. Please refer to "Compatibility' Considerations for 
Transportable Tablespaces" on page 12-34 for a discussion of 
database compatibilit;' for transporting tablespaces across release 
levels. 



Introduction to Transportable Tablespaces 



You can use the Transportable Tablespaces feature to copv a set of tablespaces from 
one Oracle Database to another 



Note: This method for transporting tablespaces requires that vou 
place the tablespaces to be transported in read-only mode until you 
complete the transporting process. If this is undesirable, you can use 
the Transportable Tablespaces from Backup feature, described in 
Oracle Database Backup and Recover}/ User's Guide. 



The tablespaces being transported can be either dictionary managed or locallv 
managed. Starting with Oracle9j, the transported tablespaces are not required to be of 
the same block size as the target database standard block size. 

Moving data using transportable tablespaces is much faster than performing either an 
export/import or unload/load of the same data. This is because the datafiles 
containing all of the actual data are just copied to the destination location, and vou use 
Data Pump to transfer only the metadata of the tablespace objects to the new database, 

Note: Beginning with Oracle Database llg Release 1, you must 
use Data Pump for transportable tablespaces. The only 
circumstance under which you can use the original import and 
export utilities, IMP and EXP, is for a backward migration of 
XMLTvpe data to a database version Wg Release 2 or earlier Refer 
to Oracle Database Utilities for more information on these utilities 
and to Oracle XML DB Developer's Guide for more information on 
XMLTypes. 



The transportable tablespace feature is useful in a number of scenarios, including: 
Exporting and importing partitions in data warehousing tables 
Publishing structured data on CDs 

Copying multiple read-only versions of a tablespace on multiple databases 
Archiving historical data 
Performing tablespace point-in-time-recovery (TSPITR) 
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These scenarios are discussed in "Using Transportable Tablespaces: Scenarios" on 
page 12-42, 

There are two wavs to transport a tablespace: 

■ Manually, following the steps described in this section. This involves issuing 
commands to SQL'Plus, RMAN, and Data Pump, 

■ Using the Transport Tablespaces Wizard in Enterprise Manager 
To run the Transport Tablespaces Wizard; 

1. Log in to Enterprise Manager with a user that has the EXP_FULL_DATABASE 
role. 

2. Click the Maintenance link to go to the Maintenance tab. 

3. Under the heading Move Database Files, click Transport Tablespaces. 

See Also: Oracle DatabiKC Data Warclioiisirig Guide for information 
about using transportable tablespaces in a data warehousing 
environment 

About Transporting Tablespaces Across Platforms 

Starting with Oracle Database 11^, vou can transport tablespaces across platforms. 
This functionalit\' can be used to: 

■ Allow a database to be migrated from one platform to another 

■ Provide an easier and more efficient means for content providers to publish 
structured data and distribute it to customers running Oracle Database on 
different platforms 

■ Simplify the distribution of data from a data warehouse environment to data 
marts, which are often running on smaller platforms 

■ Enable the sharing of read-onlv tablespaces between Oracle Database installations 
on different operating svstems or platforms, assuming that vour storage svstem is 
accessible from those platforms and the platforms all have the same endianness, as 
described in the sections that follow 

Many, but not all, platforms are supported for cross-platform tablespace transport. 
You can query the V$TRANSPORTABLE_PLATFORM view to see the platforms that are 
supported, and to determine each platform's endian format (byte ordering). The 
following query displays the platforms that support cross- platform tablespace 
transport: 

SeL> COLUMN PLATFORM_NflME FOHMAT A32 

SQL> SELECT ' FROM V3TRMSP0RTABLE_PLATF0RM; 



PLATFORH_ID 


PLATFORM_NSME 


EHDIM_FOHMftT 


1 


Solaris[tm] OE {32-bit) 


Big 


2 


Solaris[tm] OE {54-bit) 


Big 


7 


Microsoft Windows lA (32-bit) 


Little 


10 


Linux lA (32-bit} 


Little 


6 


AIX-Based Systems (64-bit) 


Big 


3 


HP-UX (64-bit) 


Big 


5 


HP Tm64 UNIX 


Little 


4 


HP-UX lA [64-bit} 


Big 


11 


Linux lA [64-bit} 


Little 


15 


HP Open VMS 


Little 
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8 Microsoft Windows lA (64-bit) Little 

9 IBM zSeries Based Linux Big 

13 Linux 64-bit for fiMD Little 

16 Apple Mac OS Big 

12 Microsoft Windows 64-bit for AMD Little 
n Solaris Operating System (x86] Little 

16 rows selected. 

If the source platform and the target platform are of different endianness, then an 
additional step must be done on either the source or target platform to convert the 
tablespace being transported to the target format. If they are of the same endianness, 
then no conversion is necessary and tablespaces can be transported as if thev were on 
the same platform. 

Before a tablespace can be transported to a different platform, the datafile header must 
identify the platform to which it belongs. In an Oracle Database with compatibility set 
to 10,0,0 or later, you can accomplish this by making the datafile read/write at least 
once. 

Limitations on Transportable Tablespace Use 

Be aware of the following limitations as you plan to transport tablespaces: 

■ The source and target database must use the same character set and national 
character set. 

■ You cannot transport a tablespace to a target database in which a tablespace with 
the same name alreadv exists. However, you can rename either the tablespace to 
be transported or the destination tablespace before the transport operation. 

■ Objects with underlying objects (such as materialized views) or contained objects 
(such as partitioned tables) are not transportable unless all of the underlying or 
contained objects are in the tablespace set. 

■ Encrypted tablespaces have the following the limitations: 

- Before transporting an encrypted tablespace, you must copv the Oracle wallet 
manually to the destination database, unless the master encr}'ption key is 
stored in a Hardware Securit}' Module (HSM) device instead of an Oracle 
wallet When copying the wallet, the wallet password remains the same in the 
destination database. However, it is recommended that you change the 
password on the destination database so that each database has its own wallet 
password. See Oracle Database Advanced Security Administrator's Guide for 
information about HSM devices, about determining the location of the Oracle 
wallet, and about changing the wallet password with Oracle Wallet Manager 

- You cannot transport an encrypted tablespace to a database that already has 
an Oracle wallet for transparent data encryption. In this case, you must use 
Oracle Data Pump to export the tablespace's schema objects and then import 
them to the destination database. You can optionally take advantage of Oracle 
Data Pump features that enable vou to maintain encryption for the data while 
it is being exported and imported. See Oracle Database Utilities for more 
information. 

- You cannot transport an encrypted tablespace to a platform with different 
endianness. 

■ Tablespaces that do not use block encryption but that contain tables with 
encrypted columns cannot be transported. You must use Oracle Data Pump to 
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export and import the tablespaces schema objects. You can take advantage of 
Oracle Data Pump features that enable you to maintain encryption for the data 
while it is being exported and imported. See Oracle Database Ulilitics for more 
information, 

■ Beginning with Oracle Database 10^ Release 2, vou can transport tablespaces that 
contain XMLTypes. Beginning with Oracle Database Ug Release 1, you must use 
onlv Data Pump to export and import the tablespace metadata for tablespaces that 
contain XMLTypes. 

The following querv returns a list of tablespaces that contain XMLTypes: 

select distinct p. tablespace_name from dba_tableE paces p, 
dba_xml_tables x, dba_UEers u, all_all_tables t where 
t.table_riame=x. table_naiiie and t . tablespace_name=p . tablespace_naiiLe 
and x.owner=u.usemame 

See Oracle XML DB Developer's Guide for information on XMLTypes. 
Transporting tablespaces with XMLTypes has the following limitations: 

- The target database must have XML DB installed. 

- Schemas referenced bv XMLType tables cannot be the XML DB standard 
schemas, 

- Schemas referenced by XMLType tables cannot have cyclic dependencies. 

- XMLType tables with row level security are not supported, because they 
cannot be exported or imported. 

- If the schema for a transported XMLType table is not present in the target 
database, it is imported and registered. If the schema already exists in the 
target database, an error is returned unless the ignore=Y option is set 

- If an XMLType table uses a schema that is dependent on another schema, the 
schema that is depended on is not exported. The import succeeds only if that 
schema is already in the target database. 

Additional limitations include the following: 

Advanced Queues Transportable tablespaces do not support 8.0-compatible 
advanced queues with multiple recipients. 

SYSTEM Tablespace Objects You cannot transport the SYSTEM tablespace or 
objects owned by the user SYS, Some examples of such objects are PL /SQL, Java 
classes, callouts, views, synonyms, users, privileges, dimensions, directories, and 
sequences. 

Opaque Types Types whose interpretation is application-specific and opaque to the 
database (such as RAW, BFILE, and the Any Types) can be transported, but they are not 
converted as part of the cross-platform transport operation. Their actual structure is 
known only to the application, so the application must address any endianness issues 
after these types are moved to the new platform. Types and objects that use these 
opaque types, either directly or indirectly, are also subject to this limitation, 

Floating-Point Numbers BINARY_FL0AT and BINARY_D0UBLE types are 
transportable using Data Pump, 
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Compatibility Considerations for Transportable Tabiespaces 

When you create a transportable tablespace set, Oracle Database computes the lowest 
compatibility level at which the target database must run. This is referred to as the 
compatibility level of the transportable set. Beginning with Oracle Database 11^, a 
tablespace can always be transported to a database with the same or higher 
compatibility setting, whether the target database is on the same or a different 
platform. The database signals an error if the compatibility level of the transportable 
set is higher than the compatibility level of the target database. 

The following table shows the minimum compatibility requirements of the source and 
target tablespace in various scenarios. The source and target database need not have 
the samecompatibilitv setting. 

Table 12-1 Minimum Compatibility Requirements 

Minimum Compatibility Setting 



Transport Scenario Source Database Target Database 

Databases on the same platform 8.0 8.0 

Tablespace with different database block 9.0 9.0 

size than the target database 

Databases on different platforms 10.0 10.0 

Transporting Tablespaces Between Databases: A Procedure and Example 

The foUov/ing steps summarize the process of transporting a tablespace. Details for 
each step are provided in the subsequent example. 

1. For cross-platform transport, check the endian format of both platforms by 
querying the VSTRANSPORTABLE_PLATFORM view. 

Ignore this step if you are transporting your tablespace set to the same platform, 

2. Pick a self-contained set of tablespaces. 

3. Generate a transportable tablespace set. 

A transportable tablespace set (or transportable set) consists of datafiles for the 
set of tablespaces being transported and an export file containing structural 
information (metadata) for the set of tablespaces. You use Data Pump to perform 
the export. 

If vou are transporting the tablespace set to a platform with different endianness 
from the source platform, you must convert the tablespace set to the endianness of 
the target platform. You can perform a source-side conversion at this step in the 
procedure, or you can perform a target-side conversion as part of step 4, 

Note: This method of generating a transportable tablespace requires 
that you temporarily make the tablespace read-oni}'. If this is 
undesirable, you can use the alternate method known as transportable 
tablespace from backup. See Oracle Database Backup and Recovery User's 
Guide for details, 

4. Transport the tablespace set. 

Copy the datafiles and the export file to a place that is accessible to the target 
database. 
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If vou have transported the tablespace set to a platform with different endianness 
from the source platform, and you have not performed a source-side conversion to 
the endianness of the target platform, you should perform a target-side conversion 
now. 

5. Import the tablespace set. 

Invoke the Data Pump utility to import the metadata for the set of tablespaces into 
the target database. 

Example 

The steps for transporting a tablespace are illustrated more fully in the example that 
follows, where it is assumed the following datafiles and tablespaces exist: 

Tablespace Datafile . 

sale3_l /u01/oracle/oradata/saleEdb/Eales_101.dbf 

sales_2 /uOl /oracle /oradata/saleEdb/sales_201.dbf 



Step 1: Determine if Platforms are Supported and Determine Endianness 

This step is only necessary if you are transporting the tablespace set to a platform 
different from the source platform. 

If vou are transporting the tablespace set to a platform different from the source 
platform, then determine if cross-platform tablespace transport is supported for both 
the source and target platforms, and determine the endianness of each platform. If 
both platforms have the same endianness, no conversion is necessarv. Otherwise you 
must do a conversion of the tablespace set either at the source or target database. 

If you are transporting sales_l and sales_2 to a different platform, you can 
execute the following quer\' on each platform. If the querv returns a row, the platform 
supports cross-platform tablespace transport. 

SELECT d.PLATFORM_HME, ENDIM_FORMAT 

FROM VSTHMSPOETABLE_PLATFORM tp, VSDATABA3E d 
MHERE tp.PLATFORM_HME = d. PIATFOEM_NMEr 

The following is the query result from the source platform: 

PLATFORM MftME ENDIM FOEMftT 



Solaris [tMii] OE (32-bit) Big 

The following is the result from the target platform: 

PLATFORM_MftME ENDIM_FOEMA.T 

Microsoft Windows HT Little 

You can see that the endian formats are different and thus a conversion is necessarv 
for transporting the tablespace set. 

Step 2: Picl< a Self-Contained Set of Tablespaces 

There may be logical or physical dependencies between objects in the transportable set 
and those outside of the set. You can only transport a set of tablespaces that is 
self-contained. In this context "self-contained" means that there are no references from 
inside the set of tablespaces pointing outside of the tablespaces. Some examples of self 
contained tablespace violations are: 
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An index inside the set of tablespaces is for a table outside of the set of tablespaces. 



Note: It is not a violation if a corresponding index for a table is 
outside of the set of tablespaces. 



■ A partitioned table is partially contained in the set of tablespaces. 

The tablespace set you want to copy must contain either all partitions of a 
partitioned table, or none of the partitions of a partitioned table. If you want to 
transport a subset of a partition table, you must exchange the partitions into tables, 

■ A referential integritj' constraint points to a table across a set boundary. 

When transporting a set of tablespaces, you can choose to include referential 
integrity constraints. However, doing so can affect whether or not a set of 
tablespaces is self-contained. If vou decide not to transport constraints, then the 
constraints are not considered as pointers, 

■ A table inside the set of tablespaces contains a LOB column that points to LOBs 
outside the set of tablespaces. 

■ An XML DB schema (',xsd) that was registered bv user A imports a global schema 
that was registered by user B, and the following is true: the default tablespace for 
user A is tablespace A, the default tablespace for user B is tablespace B, and only 
tablespace A is included in the set of tablespaces. 

To determine whether a set of tablespaces is self-contained, you can invoke the 

TRANSPORT_SET_CHECK procedure in the Oracle supplied package DBMS_TTS, You 
must have been granted the EXECUTE_CATALOG_ROLE role (initially signed to SYS) to 
execute this procedure. 

When you invoke the DBMS_TTS package, you specify the list of tablespaces in the 
transportable set to be checked for self containment. You can optionallv specifv if 
constraints must be included. For strict or full containment, you must additionally set 
the TTS_FULL_CHECK parameter to TRUE, 

The strict or full containment check is for cases that require capturing not onlv 
references going outside the transportable set, but also those coming into the set, 
Tablespace Point-in-Time Recover}' (TSPITR) is one such case where dependent 
objects must be fully contained or fuUv outside the transportable set. 

For example, it is a violation to perform TSPITR on a tablespace containing a table t 
but not its index i because the index and data will be inconsistent after the transport 
A full containment check ensures that there are no dependencies going outside or 
coming into the transportable set. See the example for TSPITR in the Oracle Database 
Backup and Recover}/ User's Guide. 

Note: The default for transportable tablespaces is to check for self 
containment rather than full containment. 



The following statement can be used to determine whether tablespaces saleE_l and 
sales_2 are self-contained, with referential integrit}' constraints taken into 
consideration (indicated by TRUE), 

EXECUTE DBMS_TTS,TRANSPORT_SET_CHECK{ 'sales_l,sales_2' , TRUE) ; 

After invoking this PL/SQL package, you can see all violations by selecting from the 
TRANSPORT_SET_VIOLATIONS view. If the set of tablespaces is self-contained, this 
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view is eniptv, Tlie following example illustrates a case where there are two violations: 
a foreign key constraint, d.ept_f k, across the tablespace set boundary, and a 
partitioned table, jim. sales, that is partially contained in the tablespace set. 

SeL> 3EI£CT ' FROM THANSPORT_SET_VIOLATIONS ; 

VIOLATIONS 

Constraint DEPT.fK between table JIM.EMP in tablespace SALES_1 and table 

JIM. DEFT in tablespace OTHER 

Partitioned table JIM. SALES is partially contained in the transportable set 

These violations must be resolved before sales_l and sales_2 are transportable. As 
noted in the next step, one choice for bypassing the integrit}' constraint violation is to 
not export the integrit;' constraints. 

See Also: 

■ Oracle Database PL/SQL Packages and Types Reference for more 
information about the DBMS_TTS package 

■ Orach Database Backup and Recovery User's Guide for information 
specific to using the DBMS_TTS package for TSPITR 

Step 3: Generate a Transportable Tablespace Set 

Any privileged user can perform this step. However, you must have been assigned the 
EXP_FULL_DATABASE role to perform a transportable tablespace export operation. 



Note: This method of generating a transportable tablespace requires 
that you temporarily make the tablespace read-only. If this is 
undesirable, you can use the alternate method known as transportable 
tablespace from backup. See Oracle Database Backup and Recovery User's 
Guide for details. 



After ensuring vou have a self-contained set of tablespaces that you want to transport, 
generate a transportable tablespace set by performing the following actions: 

1 . Make all tablespaces in the set you are copying read-only. 

SQL> ALTER TABLESPACE sales_l READ OHLY; 
Tablespace altered. 

SQL> ALTER TABLESPACE sales_2 READ OHLY; 
Tablespace altered. 

2. Invoke the Data Pump export utilit}' on the host system and specify which 
tablespaces are in the transportable set. 

SQL> HOST 

5 EXPDP systsa/password DUMPFILE=expdat.dmp DIRECTORY=dpump_dir 
TRANSP0RT_TABLESPACE3 = salesj, EaleE_2 

You must always specify TRANS PORT_TABLE SPACES, which determines the 
mode of the export operation. In this example: 
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■ The DUMPFILE parameter specifies tlie name of tlie structural information 
export file to be created, expdat . drap. 

■ The DIRECTORY parameter specifies the default directory object that points to 
the operating system or Automatic Storage Management location of the dump 
file. You must create the DIRECTORY object before invoking Data Pump, and 
you must grant the READ and WRITE object privileges on the directory to 
PUBLIC. See Oracle Database SQL Language Reference for information on the 
CREATE DIRECTORY command. 

■ Triggers and indexes are included in the export operation by default. 

If vou want to perform a transport tablespace operation with a strict containment 
check, use the TRANSPORT_FULL_CHECK parameter, as shown in the following 
example: 

EXPDP system/ password DUMPFILE=expdat.diiLp DIRECTORY = dpump_dir 

TRM3PORT_TABLESPACES=saleE_l,EaleE_2 TRMS PORT_FULL_CHECK=Y 

In this example, the Data Pump export utility verifies that there are no 
dependencies between the objects inside the transportable set and objects outside 
the transportable set. If the tablespace set being transported is not self-contained, 
then the export fails and indicates that the transportable set is not self-contained. 
You must then return to Step 1 to resolve all violations. 



Notes: The Data Pump utility is used to export onlv data 
dictionary structural information (metadata) for the tablespaces. No 
actual data is unloaded, so this operation goes relatively quickly 
even for large tablespace sets. 



3. When finished, exit back to SQL'Plus: 

S EXIT 

See Also: Oracle Database Utilities for information about using the 
Data Pump utilit}' 

If EaleE_l and 3ales_2 are being transported to a different platform, and the 
endianness of the platforms is different, and if vou want to convert before transporting 
the tablespace set, then convert the datafiles composing the sales_l and sales_2 
tablespaces: 

4. From SQL*Plus, return to the host svstem: 

SQL> HOST 

5. The RMAN CONVERT command is used to do the conversion. Start RMAN and 
connect to the target database: 

$ RMAN TARGET / 

Recovery Manager: Release 10.1.0.0.0 

Copyright (c) 1995, 2003, Oracle Corporation. All rights reserved. 

connected to target database: salesdb (DBID=3295731590) 
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6. Convert the datafiles into a temporary location on the source platform. In this 
example, assume that the temporary location, directory / temp, has already been 
created. The converted datafiles are assigned names by the system. 

EMAH> CONVERT TABLESPACE EaleE_l,Eales_2 
2> TO PLATFORM 'Microsoft Windows NT' 
3> FORMAT '/temp/'iU' ; 

Starting backup at 08-APR-03 

"using target database control file instead of recovery catalog 

allocated channel: 0RA_DISK_1 

channel 0RA_DISK_1 : sid=ll devtype=DISK 

channel 0RA_DISK_1 ; starting datafile conversion 

input datafile fno=00005 name=/u01/oracle/oradata/salesdb/sales_101.dbf 

converted dataf ile=/tenip/data_D-10_I-32 95731590_TS-ADMIH_TBS_FNO-5_05ek24v5 

channel 0RA_DISK_1 : datafile conversion complete, elapsed time: 00:00:15 

channel 0RA_DISK_1 : starting datafile conversion 

input datafile fno=00004 name=/u01/oracle/oradata/salesdb/sales_101.dbf 

converted datafile=/teiii>/data_D-10_I-32 95731590_TS-EXMPI£_FNO-4_06ek24vl 

channel 0RA_DISK_1 : datafile conversion complete, elapsed time: 00:00:45 

Finished backup at 08-APR-03 

See Also: Oracle Database Backup and Recovery Reference for a 
description of the RMAN COHVERT command 

7. Exit Recovery Manager: 

RMAN> exit 

Recovery Manager complete. 

Step 4: Transport the Tablespace Set 

Transport both the datafiles and the export file of the tablespaces to a place that is 
accessible to the target database. 

If both the source and destination are files systems, you can use: 

■ Any facility for copying flat files (for example, an operating system copy utility or 
ftp) 

■ The DBMS_FILE_TRANSFER package 
. RMAN 

■ Any facility for publishing on CDs 

If either the source or destination is an Automatic Storage Management (ASM) disk 
group, you can use: 

■ ftp to or from the / sys/asm virtual folder in the XML DB repository 
See Oracle Database Storage Administrator's Guide for more information. 

■ The DBMS_FILE_TRANSFER package 
. RMAN 
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Caution: Exercise caution when using the UNIX dd utility to copy 
raw-device files between databases. The dd utilit}' can be used to 
copy an entire source raw-device tile, or it can be invoked with 
options that instruct it to copy only a specific range of blocks from 
the source raw-device file. 

It is difficult to ascertain actual datafile size for a raw-device file 
because of hidden control information that is stored as part of the 
datafile. Thus, it is advisable when using the dd utility to specify 
copying the entire source raw-device file contents. 

If you are transporting the tablespace set to a platform with endianness that is 
different from the source platform, and vou have not vet converted the tablespace set, 
you must do so now. This example assumes that vou have completed the following 
steps before the transport: 

1. Set the source tablespaces to be transported to be read-only. 

2. Use the export utUity to create an export file (in our example, expdat.dmp). 

Dataf lies that are to be converted on the target platform can be moved to a lemporarv 
location on the target platform. However, all datafiles, whether already converted or 
not, must be moved to a designated location on the target database. 

Now use RMAN to convert the necessary transported datafiles to the endian format of 
the destination host format and deposit the results in /orahome/dbs, as shown in this 
hypothetical example: 

RMfiN> CONVERT DATAFILE 

2> 7hq/finance/worl;/trii/tbs_31.f' , 

l> 7hq/firiance/woirl;/tru/tbs_32.f' , 

4> ' /hq/firiance/worlt/trii/tbs_41.f ' 

5> TO PLATFOEM="Solaris[tm] OE (32-bit)" 

6> FROM PLftTFORM="HP TRii54 UMIX" 

7> DB_FIIE_NME_CONVERT= 

8> " /hq/ finance /work/ tru/ " , "/hq/finance/dbs/tm" 

9> PMALLELISM=5 ; 

You identify the datafiles b\' filename, not b\' tablespace name. Until the tablespace 
metadata is imported, the local instance has no way of knowing the desired tablespace 
names. The source and destination platforms are optional. RMAN determines the 
source platform by examining the datafile, and the target platform defaults to the 
platform of the host running the conversion. 

See Also: "Copving Files Using the Database Server" on 
page 13-12 for information about using the 

DBMS_FILE_TRANSFER package to copy the files that are being 
transported and their metadata 
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Step 5: Import the Tablespace Set 



Note: If you are transporting a tablespace of a different block size 
than the standard block size of the database receiving the 
tablespace set, then you must first have a DB_rjK_CACHE_SIZE 
initialization parameter entry in the receiving database parameter 
file. 

For example, if you are transporting a tablespace with an 8K block 
size into a database with a 4K standard block size, then you must 
include a DB_8K_CACHE_SI ZE initialization parameter entry in the 
parameter file. If it is not already included in the parameter file, this 
parameter can be set using the ALTER SYSTEM SET statement. 

See Oracle Database Reference for information about specifving 
values for the DB_rjK_CACHE_SIZE initialization parameter. 

Any privileged user can perform this step. To import a tablespace set, perform the 
following tasks: 

1. Import the tablespace metadata using the Data Pump Import utility, impdp: 

IMPDP system/password DUMPFILE=expdat.diiLp DIRECTORY=dpunip_dir 
TRABSPORT_DATAFILES= 
/salesdb/sales_101.dbf, 
/salesdb/sales_2 01.dbf 
REMAP_3CHEMA={dcrarmey:smith) REMAP_3CHEMA= (jfee: Williams) 

n this example we specify the following: 

The DUMP FILE parameter specifies the exported file containing the metadata 
for the tablespaces to be imported. 

The DIRECTORY parameter specifies the directory object that identifies the 
location of the dump file. 

The TRAHSPORT_DATAFILES parameter identifies all of the datafiles 
containing the tablespaces to be imported. 

The REMAP_SCHBMA parameter changes the ownership of database objects. If 
you do not specify REMAP_SCHEMA, all database objects (such as tables and 
indexes) are created in the same user schema as in the source database, and 
those users must already exist in the target database. If they do not exist, then 
the import utility returns an error. In this example, objects in the tablespace set 
owned by dcranney in the source database will be owned bv smith in the 
target database after the tablespace set is imported. Similarly, objects owned 
by j fee in the source database will be owned bv v;illiams in the target 
database. In this case, the target database is not required to have users 
dcranney and j fee, but must have users smith and williams. 

After this statement executes successfully, all tablespaces in the set being copied 
remain in read-only mode. Check the import logs to ensure that no error has 
occurred. 

When dealing with a large number of datafiles, specifying the list of datafile 
names in the statement line can be a laborious process. It can even exceed the 
statement line limit. In this situation, you can use an import parameter file. For 
example, you can invoke the Data Pump import utility as follows: 

IMPDP system/ password PARFILE= 'par . f ' 
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where the parameter file, par . f contains the following: 

DIBEC:T0RY= dpuinp_d i r 

DUMPFILE=expdat . dmp 

TRAHSPORT_DATAFILES= " '/db/salesjan' , 7db/sales_feb '" 

EEMAP_SCHEMft=dcranneY:sndth 

REMAP_SCHEMft= j fee : Williams 

See Also: Oracle Database Utilities for information about using the 
import utilitv 

2. If required, put the tablespaces into rend/write mode as follows: 

ALTER TABLESPACE saIeE_l READ WHITE; 
ALTER TABLESPACE sales_2 READ 'rfRITE; 

Using Transportable Tablespaces: Scenarios 

The following sections describe some uses for transportable tablespaces: 
Transporting and Attaching Partitions for Data Warehousing 
Publishing Structured Data on CDs 

Mounting the Sam.e Tablespace Read-Onlv on Multiple Databases 
Archiving Historical Data Using Transportable Tablespaces 
Using Transportable Tablespaces to Perform TSPITR 

Transporting and Attaching Partitions for Data Warehousing 

Typical enterprise data warehouses contain one or more large fact tables. These fact 
tables can be partitioned bv date, making the enterprise data warehouse a historical 
database. You can build indexes to speed up star queries. Oracle recommends that you 
build local indexes for such historicallv partitioned tables to avoid rebuilding global 
indexes every time you drop the oldest partition from the historical database. 

Suppose every month you would like to load one month of data into the data 
warehouse. There is a large fact table in the data warehouse called sales, which has 
the following columns: 

CREATE TABLE sales {invDice_no HUHBER, 
salejear INT NOT NULL, 
salejnonth INT NOT NULL, 
sale_day INT NOT NULL) 

PARTITION BY RANGE (sale_year, sale_month, sale_day) 
{partition ]an98 VALUES LESS THAN (1998, 2, 1), 

partition feb98 VALUES LESS THAN (1998, 3, 1), 

partition mar98 VALUES LESS THAN (1998, 4, 1), 

partition apr98 VALUES LESS THAN (1998, 5, 1), 

partition may98 VALUES LESS THAN (1998, 6, 1), 

partition jun98 VALUES LESS THAN (1998, 7, 1)); 

You create a local non-prefixed index: 

CREATE INDEX sales_index ON sales (invoics_no) LOCAL; 

Initially, all partitions are empt\', and are in the same default tablespace. Each month, 
you want to create one partition and attach it to the partitioned sales table. 
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Suppose it is July 1998, and you would like to load the July sales data into the 
partitioned table. In a staging database, you create a new tablespace, ts_jul. You also 
create a table, jul_sales, in that tablespace with exactly the same column types as 
the sales table. You can create the table jul_Eale3 using the CREATE TABLE ... AS 
SELECT statement After creating and populating jul_EaleE, vou can also create an 
index, jul_Eale_index, for the table, indexing the same column as the local index in 
the sales table. After building the index, transport the tablespace ts_jul to the data 
warehouse. 

In the data warehouse, add a partition to the sales table for the July sales data. This 
also creates another partition for the local non-prefixed index: 

ALTER TABLE sales ADD PARTITION jul98 VALUES LESS THAN [1998, 8, 1); 

Attach the transported table jul_EaleE to the table sales by exchanging it with the 
new partition: 

ALTES TABLE sales EXCHAHGE PARTITIOH jul98 WITH TABLE jul_sales 
INCLUDIHG INDEXES 
WITHOUT VALIDATION; 

This statement places the July sales data into the new partition jul9 8, attaching the 
new data to the partitioned table. This statement also converts the index 
jul_sale_index into a partition of the local index for the sales table. This 
statement should return immediately, because it only operates on the structural 
information and it simplv switches database pointers. If you know that the data in the 
new partition does not overlap with data in previous partitions, you are advised to 
specify the WITHOUT VALIDATION clause. Otherwise, the statement goes through all 
the new data in the new partition in an attempt to validate the range of that partition. 

If all partitions of the sales table came from the same staging database (the staging 
database is never destroyed), the exchange statement always succeeds. In general, 
however, if data in a partitioned table comes from different databases, it is possible 
that the exchange operation may fail. For example, if the jan9 8 partition of sales did 
not come from the same staging database, the preceding exchange operation can fail, 
returning the following error: 

ORA-19728: data object number conflict between table JUL_SALES and partition JM98 
in table SALES 

To resolve this confhct, move the offending partition by issuing the following 
statement: 

ALTER TABLE sales MOVE PARTITIOH jan98; 

Then retry the exchange operation. 

After the exchange succeeds, you can safely drop jul_sales and jul_sale_index 
(both are now empty). Thus you have successfully loaded the July sales data into your 
data warehouse. 

Publishing Structured Data on CDs 

Transportable tablespaces provide a way to publish structured data on CDs, A data 
provider can load a tablespace with data to be published, generate the transportable 
set, and copy the transportable set to a CD, This CD can then be distributed. 

When customers receive this CD, they can add the CD contents to an existing database 
without having to copy the datafiles from the CD to disk storage. For example, 
suppose on a Windows NT machine D: drive is the CD drive. You can import a 
transportable set with datafile catalog, f and export file expdat . dmp as follows: 
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IHPDP system/password DUMPFILE=expdat.diiLp DIRECTORY=dpunip_dir 
TEMSPORT_DATAFILES= ' D: \catalog. E ' 

You can remove the CD while the database is still up. Subsequent queries to the 
tablespace return an error indicating that the database cannot open the datafiles on the 
CD, However, operations to other parts of the database are not affected. Placing the 
CD back into the drive makes the tablespace readable again. 

Removing the CD is the same as removing the datafiles of a read-only tablespace. If 
you shut down and restart the database, the database indicates that it cannot find the 
removed datafile and does not open the database (unless you set the initialization 
parameter READ_OWLY_OPEN_DELAYED to TRUE), When 

READ_ONLY_OPEN_DELAYED is set to TRUE, the database reads the file only when 
someone queries the transported tablespace. Thus, when transporting a tablespace 
from a CD, you should always set the READ_ONLY_OPEN_DELAYED initialization 
parameter to TRUE, unless the CD is permanently attached to the database. 

Mounting the Same Tablespace Read-Only on Multiple Databases 

You can use transportable tablespaces to mount a tablespace read-only on multiple 
databases. In this way, separate databases can share the same data on disk instead of 
duplicating data on separate disks. The tablespace datafiles must be accessible by all 
databases. To avoid database corruption, the tablespace must remain read-only in all 
the databases mounting the tablespace. 

The following are two scenarios for mounting the same tablespace read-onlv on 
multiple databases: 

■ The tablespace originates in a database that is separate from the databases that 
will share the tablespace. 

You generate a transportable set in the source database, put the transportable set 
onto a disk that is accessible to all databases, and then import the metadata into 
each database on which you want to mount the tablespace, 

■ The tablespace already belongs to one of the databases that will share the 
tablespace. 

It is assumed that the datafiles are already on a shared disk. In the database where 
the tablespace already exists, you make the tablespace read-only, generate the 
transportable set, and then import the tablespace into the other databases, leaving 
the datafiles in the same location on the shared disk. 

You can make a disk accessible by multiple computers in several ways. You can use 
either a cluster file system or raw disk. You can also use network file system (NFS), 
but be aware that if a user queries the shared tablespace while NFS is down, the 
database wiU hang until the NFS operation times out. 

Later, you can drop the read-only tablespace in some of the databases. Doing so does 
not modifv the datafiles for the tablespace. Thus, the drop operation does not corrupt 
the tablespace. Do not make the tablespace read/write unless onlv one database is 
mounting the tablespace. 

Archiving Historical Data Using Transportable Tabiespaces 

Since a transportable tablespace set is a self-contained set of files that can be imported 
into anv Oracle Database, you can archive old /historical data in an enterprise data 
warehouse using the transportable tablespace procedures described in this chapter. 

See Also: Oracle Database Data Warehousing Guide for more details 
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Using Transportable Tablespaces to Perform TSPITR 

You can use transportable tablespaces to perform tablespace point-in-time recovery 
(TSPITR). 

See Also: Oracle Database Backup and Recovery User's Guide for 
information about how to perform TSPITR using transportable 
tablespaces 

Moving Databases Across Platforms Using Transportable Tablespaces 

You can use the transportable tablespace feature to migrate a database to a different 
platform by creating a new database on the destination platform and performing a 
transport of all the user tablespaces. See Oracle Database Backup and Recovery User's 
Guide for more information. 

You caruiot transport the SYSTEM tablespace. Therefore, objects such as sequences, 
PL/SQL packages, and other objects that depend on the SYSTEM tablespace are not 
transported. You must either create these objects manually on the destination 
database, or use Data Pump to transport the objects that are not moved by 
transportable tablespace. 



Tablespace Data Dictionary Views 



The following data dictionar}' and dvnamic performance views provide useful 
information about the tablespaces of a database. 



View 


Description 


VSTABTiFSPACE 


Ntime Lind number of all tablespaces from the control tile. 


VSEHCRYPTED TAB TiF"? PACES 


Name and encrvption algorithm of all encrypted tablespaces. 


DBA TABLESPACES, USER TABT.FSPACES 


Descriptions of all (or user accessible) tablespaces. 


DBA_TABLES PACE_GRODPS 


Displays the tablespace groups and the tablespaces that 
belong to them. 


DBA_SEGMENTS, USER_SEGMEtTTS 


Information about segments within all (or user accessible) 
tablespaces. 


DBA_EXTEHTS, USER_EXTENTS 


Information about data extents within all (or user accessible) 

tablespaces. 


DBA_FREE_SPACE, DSER_FREE_SPACE 


Information about free extents within all (or user accessible) 
tablespaces. 


DBA_TEMP_FREE_S PACE 


Displays the total allocated and free space in each temporary 

tablespace. 


VSDATAFILE 


Information about all datafiles, including tablespace number 
of owning tablespace. 


VSTEMPFILE 


Information about all tempfiles, including tablespace number 
of owning tablespace. 


DBA_DATA_FILES 


Shows files (datafiles) belonging to tablespaces. 


DBA_TEMP_FILES 


Shows files (tempfiles) belonging to tem.porary tablespaces. 


VS TEMP_EXTENT_MAP 


Information for all extents in all locally managed temporary 

tablespaces. 


VS TEMP_EXTENT_P0OL 


For locally managed temporary tablespaces: the state of 

temporary space cached and used for bv each instance. 



Managing Tablespaces 1 2-45 



Tablespace Data Dictionary Views 









View 


Description 




VS TEMP_SPACE_HEADER 


Shows space used/free for each tempfile. 




DBA_DSERS 


Default and temporary tablespaces for all users. 




DBA_T3_QU0TAS 


Lists tablespace quotas for all users. 




VSSORT_SEGMENT 


Information about every sort segment in a given instance. The 
view is only updated when the tablespace is of the 
TEMPORARY type. 




VS TEMPSEG_USAGE 
1 


Describes temporary (sort) segment usage by user for 
temporary or permanent tablespaces. 





The following are just a few examples of using some of these views. 

See Also: Oracle Database Reference for complete description of 
these views 

Example 1: Listing Tablespaces and Default Storage Parameters 

To list the names and default storage parameters of all tablespaces in a database, use 
the following query on the DBA_TABLE SPACES view: 

SELECT TftBLESPACE_NAME "TABLESPACE", 

IHITIAL_EXTENT "IMITIAL_EXT" , 

NEXT_EXTENT "HEXT_EXT" , 

MIN_EXTENT3 "MIN_EXT" . 

MAX_EXTENT3 "MAX_EXT" . 

PCT_IHCREA3E 

FROM DBA_TABLE3PACES; 



TABLESPACE 


INITIAL_EXT 
1048576 


NEXT_EKT 
1048576 


MIH 


_EXT 
2 


MAX. 


_EXT 


PCT_IHCREASE 


EB3 




40 





SYSTEM 


106496 


106496 




1 




99 


1 


TEMP 


106496 


106496 




1 




99 





TEST TBS 


57344 


16384 




2 




10 


1 


USERS 


57344 


57344 




1 




99 


1 



Example 2: Listing the Datafiles and Associated Tablespaces of a Database 

To list the names, sizes, and associated tablespaces of a database, enter the following 
query on the DBA_DATA_FILES view: 

SELECT FILE_MAME, BLOCKS, TABLES PACE_NftME 
FROM DBA_DATA_FILES ; 



FILE_HAHE 

/U02/ORACLE/IDDB3/DBF/RBS01,DBF 

/U02/ORACLE/IDDB3/DBF/SYSTEM01.DBF 

/D02/ORACLE/IDDB3/DBF/TEMP01,DBF 

/U02/ORACLE/IDDB3/DBF/TESTTBS01,DBF 

/U02/ORACLE/IDDB3/DBF/USERS01.DBF 



BLOCKS TABLESPACE NME 



1536 


RBS 


6586 


SYSTEM 


6400 


TEMP 


6400 


TESTTBS 


384 


USERS 



Example 3: Displaying Statistics for Free Space (Extents) of Each Tablespace 

To produce statistics about free extents and coalescing activit}' for each tablespace in 
the database, enter the following query: 
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SELECT TftBLESPACE_NME "TfiBLESPACE" , FILE_ID, 


COUNT { * ) 


"PIECES", 


MM (blocks) 


"MAXIMUM" . 


HIH( blocks) 


"MINIMUM" . 


AVG (blocks) 


"AVERAGE" , 


SUM (blocks) 


"TOTAL" 


FROM DBA_FREE_3PACE 


GROUP BY TABLES PACE_NAME, FILE.ID; 


TABLESPACE FILE_ID PIECES MAXIMUM MI 


RES 


2 1 955 


SYSTEM 


1 1 119 


TEMP 


4 1 6399 


TESTTBS 


5 5 6364 


USERS 


3 1 353 



MIHIMUM AVERAGE 



TOTAL 



955 


955 


955 


119 


119 


119 


399 


6399 


6399 


3 


1278 


6390 


363 


363 


363 



PIECES shows the number of free space extents in the tablespace file, MAXIMUM and 
MINIMUM show the largest and smallest contiguous area of space in database blocks, 
AVERAGE shows the average size in blocks of a free space extent, and TOTAL shows the 
amount of free space in each tablespace file in blocks. This query is useful when you 
are going to create a new object or you know that a segment is about to extend, and 
you want to make sure that there is enough space in the containing tablespace. 
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13 



Managing Datafiles and Tempfiles 



In this chapter: 

GuideUnes for Managing Datafiles 

Creating Datafiles and Adding Datafiles to a Tablespace 

Changing Dataf ile Size 

Altering Dataf ile Availabihty 

Renaming and Relocating Datafiles 

DroppingDatafiles 

Verifying Data Blocks in Datafiles 

Copying Files Using the Database Seryer 

Mapping Files to Physical Devices 

Datafiles Data DictiDnar\' Views 

See Also: Chapter 15, "Using Oracle-Managed Files" for 
information about creating datafiles and tempfiles that are both 
created and managed by the Oracle Database seryer 



Guidelines for l\/lanaging Datafiles 



Datafiles are physical files of the operating system that store the data of all logical 
structures in the database. They must be explicitly created for each tablespace. 

Note: Tempfiles are a special class of datafiles that are associated 
only with temporary tablespaces. Information in this chapter 
applies to both datafiles and tempfiles except where differences are 
noted. Tempfiles are further described in "Creating a LocaUy 
Managed Temporarj' Tablespace" on page 12-11 



Oracle Database assigns each datafile two associated file numbers, an absolute file 
number and a relative file number, that are used to uniquely identify it These 
nunabers are described in the following table: 
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Type of File Number Description 



Absolute Uniquely identifies a datafile in the database. This file number can 

be used in many SQL statements that reference datafiles in place 
of using the file name. The absoKite file number can be found in 

theFILEtt column of the VgDATAFILE or VSTEMPFILE view, 
or in the FILE_ID column of the DBA_DATA_FILES or 
DBA_TEMP_FILES view. 

Relative Uniquely identifies a datafile within ii tablespace. For small and 

medium size databases, relative file numbers usually have the 
same value as the absolute file number However, when the 
number of datafiles in a database exceeds a threshold (typically 
1023), the relative file number differs from the absolute file 
number. In a bigfile tablespace, the relative file number is 
always 1024 (4096 on OS/390 platform). 

This section describes aspects of managing datafiles, and contains the foUowing topics: 

■ Determine tlie Number of Datafiles 

■ Determine the Size of Datafiles 

■ Place Datafiles Appropriately 

■ Store Datafiles Separate from Redo Log Files 



Determine the Number of Datafiles 



At least one datafile is required for the SYSTEM and SYSAUX tablespaces of a database. 
Your database should contain several other tablespaces with their associated datafiles 
or tempfiles. The number of datafiles that you anticipate creating for your database 
can affect the settings of initialization parameters and the specification of CREATE 
DATABASE statement clauses. 

Be aivare that your operating system might impose limits on the number of datafiles 
contained in your Oracle Database. Also consider that the number of datafiles, and 
how and where they are allocated can affect the performance of your database. 

Note: One means of controlling the number of datafiles in your 
database and simplifying their management is to use bigfile 
tablespaces, Bigfile tablespaces comprise a single, very large 
datafile and are especially useful in ultra large databases and where 
a logical volume manager is used for managing operating system 
files, BigfiJe tablespaces are discussed in "Bigfile Tablespaces" on 
page 12-6, 



Consider the following guidelines when determining the number of datafUes for vour 
database. 

Determine a Value for the DB_FILES Initialization Parameter 

When starting an Oracle Database instance, the DB_FILES initialization parameter 
indicates the amount of SGA space to reserve for datafile information and thus, the 
maximum number of datafiles that can be created for the instance. This limit applies 
for the life of the instance. You can change the value of DB_FILES (bv changing the 
initialization parameter setting), but the new value does not take effect until vou shut 
down and restart tlie instance. 
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When determining a value for DB_FILES, take the following into consideration: 

■ If the value of DB_FILES is too low, you cannot add datafiles bevond the 
DB_FILES limit without first shutting down the database. 

■ If the value of DB_FILES is too high, memory is unnecessarily consumed. 

Consider Possible Limitations Wlien Adding Datafiies to a Tabiespace 

You can add datafiles to traditional smallfile tablespaces, subject to the following 
limitations: 

■ Operating systems often impose a limit on the number of files a process can open 
simultaneously. More datafiles cannot be created when the operating svstem limit 
of open fUes is reached. 

■ Operating systems impose limits on the number and size of datafiles. 

■ The database imposes a maximum limit on the number of datafiles for any Oracle 
Database opened by any instance. This limit is operating system specific. 

■ You cannot exceed the number of datafiles specified bv the DB_FILES 
initialization parameter, 

■ When you issue CREATE DATABASE or CREATE CONTROLFILE statements, the 
MAXDATAFILES parameter specifies an initial size of the datafile portion of the 
control file. However, if you attempt to add a new file whose number is greater 
than MAXDATAFILES, but less than or equal to DB_FILE3, the control file will 
expand automatically so that the datafiles section can accommodate more files. 

Consider tlie Performance impact 

The number of datafiles contained in a tabiespace, and ultimately the database, can 
have an impact upon performance. 

Oracle Database allows more datafiles in the database than the operating system 
defined limit. The database DBWii processes can open all online datafiles. Oracle 
Database is capable of treating open file descriptors as a cache, automatically closing 
files when the number of open file descriptors reaches the operating s\' stem- defined 
limit. This can have a negative performance impact. When possible, adjust the 
operating system limit on open file descriptors so that it is larger than the number of 
online datafiles in the database. 

See Also: 

■ Your operating s}'stem specific Oracle documentation for more 
information on operating system limits 

■ Oracle Database SQL Language Reference for more information 
about the MAXDATAFILES parameter of the CREATE 

DATABASE or CREATE CONTROLFILE statement 

Determine the Size of Datafiles 

When creating a tabiespace, you should estimate the potential size of database objects 
and create sufficient datafiles. Later, if needed, vou can create additional datafiles and 
add them to a tabiespace to increase the total amount of disk space allocated to it, and 
consequently the database. Preferably, place datafiles on multiple devices to ensure 
that data is spread evenly across all devices. 
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Place Datafiles Appropriately 

Tablespace location is determined bv the physical location of the datafiles that 
constitute that tablespace. Use the hardware resources of vour computer 
appropriately. 

For example, if several disk drives are available to store the database, consider placing 
potentially contending datafiles on separate disks.This wav, when users query 
information, both disk drives can work simultaneously, retrieving data at the same 
time. 

See Also: Ornclc Database Pcrforniaiia: Tuning Guide for 
information about I/O and the placement of datafiles 

Store Datafiles Separate from Redo Log Files 

Datafiles should not be stored on the same disk drive that stores the database redo log 
files. If the datafiles and redo log files are stored on the same disk drive and that disk 
drive fails, the files cannot be used in your database recover}' procedures. 

If vou multiplex your redo log files, then the likelihood of losing all of your redo log 
files is low, so vou can store datafiles on the same drive as some redo log files. 

Creating Datafiles and Adding Datafiles to a Tablespace 

You can create datafiles and associate them with a tablespace using any of the 
statements listed in the following table. In all cases, vou can either specifv the file 
specifications for the datafiles being created, or vou can use the Oracle-managed files 
fealTire to create files that are created and managed by the database ser\'er. The table 
includes a brief description of the statement, as used to create datafiles, and references 
the section of this book where use of the statement is specifically described: 



SOL Statement 



Description 



Additional Information 



CREATE TABLESPACE 



CREATE TEMPORARY TABLESPACE 



ALTER TABLESPACE 



ALTER TABLESPACE 



CREATE DATABASE 



ALTER DATABASE 



ADD DATAFILE 



Creates a tablespace and the 
datafiles that compriBe it 

Creates a localfv-managed 
temporary tablespace and the 
tenijif/lfi (tempfiles are a special 
kind of datafile) that comprise it 

Creates and adds a datafile to a 
tablespace 



ADD TEMPFILE Creates and adds a tempfile to a 
temporary tablespace 



Creates a database and associated 
datafiles 



CREATE DATAFILE Creates a new empty datafile in 
place of an old one— useful to 
re-create a datafile that was lost 
with no backup. 



"Creating Tablespaces" 
on page 12-2 

"Creating a Locally 
Managed Temporary 
Tablespace" on 
page 12-11 

"Altering a Locally 
Managed Temporary 
Tablespace" on 
page 12-22 

"Creating a Locally 
Managed Temporary 

Tablespace" on 
page 12-11 

"Creating a Database 

with the CREATE 
DATABASE Statement" 
on page 2-4 

See Orac/i' Diibibasc 

Backiifi nmi Recovery 
User's Guide. 
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If voLL add new datafiles to a tablespace and do not fuUv specify the filenames, the 
database creates the datafiles in the default database directory' or the current directory, 
depending upon vour operating svstem. Oracle recommends you always specify a 
fullv qualified name for a datafile. Unless vou want to reuse existing files, make sure 
the new filenames do not conflict with other files. Old files that have been previously 
dropped will be overwritten. 

If a statement that creates a datafile fails, the database removes anv created operating 
svstem files. However, because of the large number of potential errors that can occur 
with file systems and storage subsystems, there can be situations where you must 
manually remove the files using operating system commands. 



Changing Datafile Size 



This section describes the various wavs to alter the size of a datafile, and contains the 
following topics: 

■ Enabling and Disabling Automatic Extension for a Datafile 

■ Manually Resizing a Datafile 

Enabling and Disabling Automatic Extension for a Datafile 

You can create datafiles or alter existing datafiles so that they automatically increase in 
size when more space is needed in the database. The file size increases in specified 
increments up to a specified maximum. 

Setting your datafiles to extend automaticaUy provides these advantages: 

■ Reduces the need for immediate intervention when a tablespace runs out of space 

■ Ensures applications will not halt or be suspended because of failures to allocate 
extents 

To determine whether a datafile is auto-extensible, query the DBA_DATA_FILES view 
andexamine the AUTOEXTENSIBLE column. 

You can specify automatic file extension by specifying an AUTOEXTEND ON clause 
lyhen you create datafiles using the following SQL statements: 

■ CREATE DATABASE 

■ ALTER DATABASE 

■ CREATE TABLESPACE 

■ ALTER TABLESPACE 

You can enable or disable automatic file extension for existing datafiles, or manually 
resize a datafile, using the ALTER DATABASE statement. For a bigfile tablespace, you 
are able to perform these operations using the ALTER TABLESPACE statement. 

The following example enables automatic extension for a datafile added to the users 
tablespace: 

ALTER TABLESPACE users 

ADD DATAFILE ' /■u02/oracle/rbdbl/userE03 .dbf ' SIZE lOH 
ADTOEXTEND ON 
NEXT 512K 
MftXSIZE 250Mr 
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The value of NEXT is the minimum size of the increments added to the file when it 
extends. The value of MAX3I ZE is the maximum size to which the file can 
automatically extend. 

The next example disables the automatic extension for the datafile, 

ALTER DATABASE DATAFILE ' /u02/oracle/rbdbl/uEers03 .dbf 
AUTOEXTEND OEF; 

See Also: Oracle Database SQL Language Reference for more 
information about the SQL statements for creating or altering 
datafiles 



Manually Resizing a Datafile 



You can manually increase or decrease the size of a datafile using the ALTER 
DATABASE statement. This enables you to add more space to your database without 
adding more datafiles. This is beneficial if you are concerned about reaching the 
maximum number of datafiles allowed in your database. 

For a bigfile tablespace you can use the ALTER TABLESPACE statement to resize a 
datafile. You are not allowed to add a datafile to a bigfile tablespace. 

Manually reducing the sizes of datafiles enables you to reclaim unused space in the 
database. This is useful for correcting errors in estimates of space requirements. 

In the next example, assume that the datafile /u0 2/oracle/rbdbl/s tuf f 01 . dbf 
has extended up to 250M, However, because its tablespace now stores smaller objects, 
the datafile can be reduced in size. 

The following statement decreases the size of datafile 

/u0 2/oracle/rbdbl/stuf f 01 .dbf: 

ALTER DATABASE DATAFILE ' /u02/oracle/rbdbl/3tuf f Ol.dbf 
RESIZE lOOM; 



Note: It is not always possible to decrease the size of a file to a 
specific value. It could be that the file contains data beyond the 
specified decreased size, in which case the database will return an 
error. 



Altering Datafile Availability 



You can alter the availabilitv of individual datafiles or tempfiles by taking them offline 
or bringing them online. Offline datafiles are unavailable to the database and cannot 
be accessed until they are brought back online. 

Reasons for altering datafile availability include the following: 

■ You want to perform an offline backup of a datafile, 

■ You want to rename or relocate a datafile. You must first take it offline or take the 
tablespace offline, 

■ The database has problems writing to a datafile and automatically takes the 
datafile offline. Later, after resolving the problem, you can bring the datafile back 
online manually. 

■ A datafile becomes missing or corrupted. You must take it offline before vou can 
open the database. 
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The datafiles of a read-only tablespace can be taken offline or brought onUne. but 
bringing a file online does not affect the read-only stiitus of the tiihlespace. You caruiot 
write to the datafUe until the tablespace is returned to the read/write state. 



Note: You can make all datafiles of a tablespace temporarily 
unavailable bv taking the tablespace itself offline. You imisl leave 
these files in the tablespace to bring the tablespace back online, 
although you can relocate or rename them following procedures 
similar to those shown in "Renaming and Relocating Datafiles" on 
page 13-8. 

For more information, see "Taking Tablespaces Offline" on 
page 12-15. 

To take a datafile offline or bring it online, you must have the ALTER DATABASE 
system privilege. To take all datafiles or tempfiles offline using the ALTER 
TABLESPACE statement, you must have the ALTER TABLESPACE or MANAGE 
TABLESPACE svstem privilege. In an Oracle Real Application Clusters environment, 
the database must be open in exclusive mode. 

This section describes waj's to alter datafile availability, and contains the following 
topics: 

. Bringing Datafiles Online or Taking Offline in ARCHIVELOG Mode 

. Taking Datafiles Offline in NOARCHIVELOG Mode 

■ Altering the Availabilit\' of All Datafiles or Tempfiles in a Tablespace 

Bringing Datafiles Online or Taking Offline in ARCHIVELOG Mode 

To bring an individual datafile online, issue the ALTER DATABASE statement and 
include the DATAFILE clause.The following statement brings the specified datafile 
online: 

ALTER DATABASE DATAFILE ' /u02/oracle/rbdbl/stuf f 01 .dbf ONLINE; 

To take the same file offline, issue the following statement: 

ALTER DATABASE DATAFILE 7u02/aracle/rbdbl/stuf f 01 .dbf OFFLINE; 

Note: To use this form of the ALTER DATABASE statement, the 
database must be in ARCHIVELOG mode. This requirement 
prevents vou from accidentally losing the datafile, since taking the 
datafile offline while in NOARCHIVELOG mode is likely to result in 
losing the fUe. 

Taking Datafiles Offline in NOARCHIVELOG Mode 

To take a datafile offUne when the database is in NOARCHIVELOG mode, use the ALTER 
DATABASE statement with both the DATAFILE and OFFLINE FOR DROP clauses. 

■ The OFFLINE keyword causes the database to mark the datafile OFFLINE, 
whether or not it is corrupted, so that you can open the database. 

■ The FOR DROP kevwords mark the datafile for subsequent dropping. Such a 
datafile can no longer be brought back online. 
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Note: This operation does not actually drop the datafile. It 
remains in the data dictionan', and you must drop it yourself using 
one of the following methods: 

■ An ALTER TABLESPACE ... DROP DATAFILE statement. 

After an OFFLIHE FOR DROP, this method works for dictionary 
managed tablespaces only. 

■ A DROP TABLESPACE ... IHCLUDING CONTENTS AND 

DATAFILES statement 

■ If the preceding methods fail, an operating system command to 
delete the datafile. This is the least desirable method, as it 
leaves references to the datafile in the data dictionary and 
control files. 

The following statement takes the specified datafile offline and marks it to be dropped: 

ALTER DATABASE DATAFILE ' /u02/oracle/rbdbl/uEers03 .dbf ' OFFLIHE FOR DROP; 

Altering the Availability of All Dataflles or Tempfiles in a Tablespace 

Clauses of the ALTER TABLESPACE statement allow vou to change the online or 
offline status of all of the dataflles or tempfiles within a tablespace. Specifically, the 
statements that affect online/offline status are: 

■ ALTER TABLESPACE ... DATAFILE {ONLINE I OFFLINE) 

■ ALTER TABLESPACE ... TEMPFILE {ONLINE I OFFLINE) 

You are required onlv to enter the tablespace name, not the individual dataflles or 
tempfUes. All of the dataflles or tempfiles are affected, but the online /offline status of 
the tablespace itself is not changed. 

In most cases the preceding ALTER TABLESPACE statements can be issued whenever 
the database is mounted, even if it is not open. However, the database iiiint not be 
open if the tablespace is the SYSTEM tablespace, an undo tablespace, or the default 
temporary tablespace. The ALTER DATABASE DATAFILE and ALTER DATABASE 
TEMPFILE statements also have ONLINE/OFFLINE clauses, however in those 
statements you must enter all of the filenames for the tablespace. 

The syntax is different from the ALTER TABLESPACE . . . ONLINE | OFFLINE 
statement that alters tablespace availabilit\', because that is a different operation. The 
ALTER TABLESPACE statement takes dataflles offline as well as the tablespace. but it 
cannot be used to alter the status of a tempomry tablespace or its tempfile(s). 



Renaming and Relocating Dataflles 



You can rename dataflles to either change their names or relocate them. Some possible 
procedures for doing this are described in the following sections: 

■ Procedures for Renam.ing and Relocating Dataflles in a Single Tablespace 

■ Procedure for Renaming and Relocating Dataflles in Multiple Tablespaces 

When vou rename and relocate dataflles with these procedures, onlv the pointers to 
the dataflles, as recorded in the database control file, are changed. The procedures do 
not phvsically rename any operating system files, nor do they copy files at the 
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operating system level. Renaming iind relocating datafiles involves several steps. Read 
the steps and examples carefully before performing these procedures. 

Procedures for Renaming and Relocating Datafiles in a Single Tablespace 

The section suggests some procedures for renaming and relocating datafiles that can 
be used for a single tablespace. You must have ALTER TABLESPACE system 
privileges. 

See Also: "Taking Tablespaces Offline" on page 12-15 for more 
information about taking tablespaces offline in preparation for 
renaming or relocating datafiles 

Procedure for Renaming Datafiles in a Single Tablespace 

To rename datafiles in a single tablespace, complete the following steps: 

1. Take the tablespace that contains the datafUes offline. The database must be open. 
For example: 

ALTES TABLESPACE users OFFLIME HORMAL; 

2. Rename the datafiles using the operating system. 

3. UsetheALTER TABLESPACE statement with the RENAME DATAFILE clause to 
change the filenames within the database. 

For example, the following statement renames the datafUes 

/u0 2/oracle/rbdbl/userl . dbf and /u02/oracle/rbdbl/user2 . dbf 
to/u0 2/oi:acle/rbdbl/users01.dbf and 
/u02/oracle/rbdbl/users02 .dbf, respectively: 

ALTES TABLESPACE users 

RENAME DATAFILE ' /u02/oracle/rbdbl/userl .dbf ' , 
' /u02/oracle/rbdbl/user2 .dbf ' 
TO '/uOa/oracle/rbdbl/usersOl.dbf ', 
'/u02/oracle/rbdbl/user302.dbf '; 

Always provide complete filenames (including their paths) to properly identify 
the old and new datafiles. In particular, specify the old datafile name exactly as it 
appears in theDBA_DATA_FILES view of the data dictionary. 

4. Back up the database. After making any structural changes to a database, always 
perform an immediate and complete backup. 

Procedure for Relocating Datafiles in a Single Tablespace 

Here is a sample procedure for relocating a datafile. 
Assume the following conditions: 

■ An open database has a tablespace named users that is made up of datafiles aU 
located on the same disk. 

■ The datafiles of the users tablespace are to be relocated to different and separate 
disk drives. 

■ You are currently connected ivith administrator privileges to the open database. 

■ You have a current backup of the database. 
Complete the following steps: 
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1 . If you do not know the specific file names or sizes, you can obtain this information 
by issuing the following querv of the data dictionary view DBA_DATA_FILES; 

SQL> SELECT FILEJfflE, BYTES FROM DBA_DATA_FILES 
2> WHERE TABLESPACE_NME = 'D3ERS'; 

FILE HAHE BYTES 



/u02/oracle/rbdbl/userE01.dbf 10240QOOQ 

/u03/oracle/rbdbl/userE[)2.cLbf 102400000 

2. Take the tablespace containing the datafiles offline: 

ALTER TABLESPACE users OFFLIHE NORMAL; 

3. Copy the datafiles to their new locations and rename them using the operating 
system. You can copy the files using the DBMS_FILE_TRANSFER package 
discussed in "Copving Files Using the Database Server" on page 13-12. 



Note: You can temporarily exit SQL*Plus to execute an operating 
system command to copy a file by using the SQL'Plus HOST 
command. 

4. Rename the datafiles within the database. 

The datafile pointers for the files that make up the users tablespace, recorded in 
the control file of the associated database, must now be changed from the old 
names to the new names. 

UselheALTER TABLESPACE .. .RENAME DATAFILE statement. 

ALTER TABLESPACE users 

REHAME DATAFILE ' /u02/oracle/rbdbl/users01.dbf' , 
' /u02/oracle/rbdbl/users02 .dbf ' 
TO '/u03/oracle/rbdbl/users01.dbf' , 
'/u04/oracle/rbdbl/users02.dbf' ; 

5. Back up the database. After making any structural changes to a database, always 
perform an immediate and complete backup. 

Procedure for Renaming and Relocating Datafiles in Multiple Tablespaces 

You can rename and relocate datafiles in one or more tablespaces using the ALTER 
DATABASE RENAME FILE statement This method is the only choice if you want to 
rename or relocate datafiles of several tablespaces in one operation. You must have the 
ALTER DATABASE system privilege. 



Note: To rename or relocate datafiles of the SYSTEM tablespace, 
the default temporary tablespace, or the active undo tablespace you 
must use this ALTER DATABASE method because vou cannot take 
these tablespaces offline. 

To rename datafiles in multiple tablespaces, follow these steps. 
1. Ensure that the database is mounted but closed. 
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Note: Optionally, the database does not have to be closed, but the 
datafiles (or tempt iles) must be offline. 



2. Copy the datafiles to be renamed to their new locations and new names, using the 
operating system. You can copy the files using the DBMS_FILE_TRAKISFER 
package discussed in "Copying Files Using the Database Server" on page 13-12. 

3. Use ALTER DATABASE to rename the fUe pointers in the database control fUe. 

For example, the following statement renames the 

datafiles/u0 2/oracle/rbdbl/sort01 . dbf and 

/u0 2/oracle/rbdbl/user3 .dbf to /uO 2 / oracle /rbdbl/ temp 1 .dbf and 
/u0 2/oracle/rbdbl/user sD3 .dbf, respectively: 

ALTER DATABASE 

RENAME FILE 7u02/oracle/rbdbl/sort01.dbf ' , 
' /u02/oracle/rbdbl/user3 .dbf ' 
TO 7u02/oracle/rbdbl/tenip01.dbf ' , 
7u02/oracle/rbdbl/iiEers03.dbf ; 

Always provide complete filenames (including their paths) to properly identify 
the old and new datafiles. In particular, specify the old datafile names exactly as 
they appear in the DBA_DATA_FILES view. 

4. Back up the database. After making any structural changes to a database, always 
perform an immediate and complete backup. 



Dropping Datafiles 



You use the DROP DATAFILE and DROP TEMPFILE clauses of the ALTER TABLE SPACE 
command to drop a single datafile or tempfile. The datafile must be empt\'. (A datafile 
is considered to be empt}' when no extents remain allocated from it.) When vou drop a 
datafile or tempfile, references to the datafile or tempfile are removed from the data 
dictionary and control files, and the physical file is deleted from the file system or 
Automatic Storage Management (ASM) disk group. 

The following example drops the datafile identified bv the alias example_df 3 . f in 
the ASM disk group DGROUPl. The datafile belongs to the example tablespace. 

ALTER TABLESPACE example DROP DATAFILE '+DGR0UPl/exan5ile_df 3 . f ' ; 

The next example drops the tem.pfile lmteinpD2 .dbf, which belongs to the Imtemp 
tablespace, 

ALTER TABLESPACE Imbenip DROP TEMPFILE '/u02/oiracle/data/lintemp02 .dbf ' ; 

This is equivalent to the following statement: 

ALTER DATABASE TEMPFILE ' /u02/oracle/data/lmteir[p02 .dbf ' DROP 
IHCLUDIHG DATAFILES; 

See Oracle Database SQL Language Reference for ALTER TABLESPACE syntax detaUs. 

Restrictions for Dropping Datafiles 

The following are restrictions for dropping datafiles and tempfUes: 

■ The database must be open. 

■ If a datafile is not emptv, it cannot be dropped. 
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If you must remove a datafile that is not empt\' and that cannot be made empty bv 
dropping schema objects, you must drop the tablespace that contains the datafile. 

You cannot drop the first or only datafile in a tablespace. 

This means that DROP DATAFILE cannot be used with a bigfile tablespace. 

You cannot drop datafiles in a read-onlv tablespace. 

You cannot drop datafiles in the SYSTEM tablespace. 

If a datafile in a locally managed tablespace is offline, it cannot be dropped. 

See Also: Dropping Tablespaces on page 12-24 



Verifying Data Blocks in Datafiles 



If vou want to configure the database to use checksums to verify data blocks, set the 
initialization parameter DB_BLOCK_CHECKSUM to TYPICAL (the default). This causes 
the DBWi; process and the direct loader to calculate a checksum for each block and to 
store the checksum in the block header when writing the block to disk. 

The checksum is verified when the block is read, but only if DB_BLOCK_CHECKSUM is 
TRUE and the last write of the block stored a checksum. If corruption is detected, the 
database returns message ORA-0157 8 and writes information about the corruption to 
the alert log. 

The value of the DB_BLOCK_CHECKSUM parameter can be changed dynamically using 
the ALTER SYSTEM statement. Regardless of the setting of this parameter, checksums 
are always used to verify data blocks in the SYSTEM tablespace. 

See Also: Oracle Database Reference for more information about the 
DB_BLOCK_CHECKSUM initialization parameter 

Copying Files Using the Database Server 

You do not necessarily have to use the operating system to copv a file within a 
database, or transfer a file betiveen databases as you would do when using the 
transportable tablespace feature. You can use the DBM3_FILE_TRANSFER package, or 
you can use Streams propagation. Using Streams is not discussed in this book, but an 
example of using the DBMS_FILE_TRANSFER package is shown in "Copying a File on 
a Local File System" on page 13-13. 

TheEBMS_FILE_TRAMSFER package can use a local file system or an Automatic 
Storage Management (ASM) disk group as the source or destination for a file transfer. 
Onlv Oracle database files (datafiles, tempfiles, controlfiles, and so on) can be involved 
in transfers to and from ASM. 

Caution: Do not use the DBMS_FILE_TRANSFER package to copy or 
transfer a file that is being modified by a database because doing so 
may result in an inconsistent file. 

On UNIX systems, the owner of a file created by the DBMS_FILE_TRAWSFER package 
is the owner of the shadow process running the instance. Normally, this owner is 
ORACLE. A file created using DBMS_FILE_TRANSFER is always writable and readable 
by all processes in the database, but non privileged users who need to read or write 
such a file directly may need access from a svstem administrator 



13-12 Oracie Database Administrator's Guide 



Copying Files Using the Database Server 



This section contains the foUowing topics: 

■ Copying a File on a Local File System 

■ Third-Parti' File Transfer 

. File Tunsfer and the DBMS_SCHEDULER Package 

■ Advanced File Transfer Mechanisms 

See Also: 

■ Oracle Streams Concepts ami Administration 

■ "Transporting Tablespaces Between Databases" on page 12-29 

■ Oracle Database PL/SQL Packages and Types Reference for a 
description of the DBMS_FILE_TRANSFER package. 

Copying a File on a Local File System 

This section includes an example that uses the COPY_FILE procedure in the 
DBMS_FILE_TEAWSFER package to copy a file on a local file system. The following 
example copies a binary file named dbl . dat from the / us r/ admin/ source 
directory to the /usr/ admin /destination directory as dbl_copY. dat on a local 
file system: 

1. InSQL'Plus, connect as an administrative user who can grant privileges and 
create directory objects using SQL. 

2. Use the SQL command CREATE DIRECTORY to create a director}' object for the 
directory from which you want to copy the file. A directory object is similar to an 
alias for the directory. For example, to create a directory object called 

SOURCE_DIR for the /usr/ admin/ source directory on vour computer system, 
execute the following statement: 

CREATE DIRECTORY 30URCE_DIR A3 ' /usr/admin/source ' ; 

3. Use the SQL command CREATE DIRECTORY to create a directory object for the 
directory into which you wiint to copy the binary file. For example, to create a 
directory object called DEST_DIR for the /usr /admin/ destination directory 
on your computer system, execute the following statement: 

CREATE DIRECTORY DEST_DIR AS ' /usr/admin/ destination' ; 

4. Grant the required privileges to the user who will run the COPY_FILE procedure. 
In this example, the s trmadmin user runs the procedure. 

GRANT EXECUTE OH DBMS_FILE_TRAHSFER TO strmadmin; 
GRANT READ OH DIRECTORY source_dir TO s trmadmin ; 
GRANT WRITE 01 DIRECTORY dest_dir TO strraadmin; 

5. Connect as s trmadmin user and provide the user password when prompted: 

CONNECT strmadinin 

6. Run the COPY_FILE procedure to copy the file: 

BEGIH 

DBM3_FILE_TRANSFER . COPY_FILE ( 

source_directory_ob]ect => '30URCE_DIR' . 

source_file_naiiie => 'dbl. dat'. 
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deEtinatioii_directory_object => ' DEST_DIR ' , 
destination_f ile_name => ' dbl_copy.dat ' 

END; 

/ 



Caution: Do not use the DBMS_FILE_TRANSFER package to copy 
or transfer a file that is being modified by a database because doing so 
may result in an inconsistent file. 



Third-Party File Transfer 

Although the procedures in the DBMS_FILE_TRANSFER package typically are 
invoked as local procedure calls, they can also be invoked as remote procedure calls. A 
remote procedure call lets you copy a file within a database even when you are 
connected to a different database. For example, you can make a copy of a file on 
database DB, even if vou are connected to another database, bv executing the following 
remote procedure call: 

DBMS_FII£_TRMSET;R.C0PY_FII£@DB{ . . . ) 

Using remote procedure calls enables you to copv a file between two databases, even if 
you are not connected to either database. For example, you can connect to database A 
and then transfer a file from database B to database C, In this example, database A is 
the third part\' because it is neither the source of nor the destination for the transferred 
file. 

A third-partv file transfer can both push and pull a file. Continuing with the previous 
example, you can perform a third-parti' file transfer if vou have a database link from A 
to either B or C, and that database has a database link to the other database. Database A 
does not need a database hnk to both B and C. 

For example, if you have a database link from A to B, and another database link from B 
to C, then you can run the following procedure at A to transfer a file from B to C; 

DBMS_FII£_TRANSFER . PUT_FILE@B ( . , . ) 

This configuration pushes the file. 

Alternatively, if vou have a database link from A to C, and another database link from 
C to B, then you can run the following procedure at database A to transfer a file from B 
toC; 

DBMS_FII£_TRANSFER . GET_FILE@C ( . , . ) 

This configuration pulls the file. 

File Transfer and the DBMS_SCHEDULER Package 

You can use the DBMS_SCHEDULER package to transfer files automatically within a 
single database and between databases, Third-partv file transfers are also supported 
by the DBMS_ SCHEDULER package. You can monitor a long-running file transfer done 
by the Scheduler using the VSSESSION_LONGOPS dynamic performance view at the 
databases reading or writing the file, Anv database links used by a Scheduler job must 
be fixed user database links. 

You can use a restartable Scheduler job to improve the reliabilitv of file transfers 
automatically, especially if there are intermittent failures. If a file transfer fails before 
the destination file is closed, then you can restart the file transfer from the beginning 
once the database has remo\'ed any partially written destination file. Hence you 
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should consider using a rest.irtable Scheduler job to transfer a file if the rest of the job 
is restartable. See Chapter 27, "Scheduling Jobs with Oracle Scheduler" for more 
information on Scheduler jobs. 



Note: If a single restartable job transfers several files, then you 
should consider restart scenarios in which some of the files have 
been transferred already and some have not been transferred vet. 



Advanced File Transfer Mechanisms 



You can create more sophisticated file transfer mechanisms using both the 
DBMS_FILE_TEAWSFER package and the DBMS_SCHEDULER package. For example, 
when several databases have a copy of the file you want to transfer, vou can consider 
fiictors such as source availability', source load, and communication bandwidth to the 
destination database when deciding which source database to contact first and which 
source databases to trv if failures occur In this case, the information about these 
factors must be available to you, and you must create the mechanism that considers 
these factors. 

As another example, when earlv completion time is more important than load, vou can 
submit a number of Scheduler jobs to transfer files in parallel. As a final example, 
knowing something about file lavout on the source and destination databases enables 
you to minimize disk contention by performing or scheduling simultaneous transfers 
onlv if thev use different I/O devices. 



Mapping Files to Physical Devices 



In an environment where datafiles are simply file system files or are created directiv 
on a raw device, it is relatively straight forward to see the association betiveen a 
tablespace and the underlying device, Oracle Database provides views, such as 
DBA_TABLESPACES, DBA_DATA_FILES, and V5DATAFILE, that provide a mapping 
of files onto devices. These mappings, along with device statistics can be used to 
evaluate I/O performance. 

However, with the introduction of host based Logical Volume Managers (LVM), and 
sophisticated storage subsystems that provide RAID (Redundant Arrav of Inexpensive 
Disks) features, it is not easy to determine file to device mapping. This poses a 
problem because it becomes difficult to determine your "hottest" files when they are 
hidden behind a "black box". This section presents the Oracle Database approach to 
resolving this problem. 

The following topics are contained in this section: 

■ Overview of Oracle Database File Mapping Interface 

■ How the Oracle Database File Mapping Interface Works 

■ Using the Oracle Database File Mapping Interface 

■ File Mapping Examples 
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Note: This section presents an overview of the Oracle Database 
file mapping interface and explains how to use the 
DBMS_STOHAGE_MAP package and dynamic performance views to 
expose the mapping of files onto phvsical devices. You can more 
easily access this functionality through the Oracle Enterprise 
Manager (EM). It provides an easy to use graphical interface for 
mapping files to physical devices. 



Overview of Oracle Database File Mapping Interface 

To acquire an understanding of I/O performance, one must have detailed knowledge 
of the storage hierarchv in which files reside. Oracle Database provides a mechanism 
to show a complete mapping of a file to intermediate lavers of logical volumes to 
actual phvsical devices. This is accomplished though a set of dvnamic performance 
views (VS views). Using these views, you can locate the exact disk on which any block 
of a file resides. 

To build these views, storage vendors must provide mapping libraries that are 
responsible for mapping their particular I/O stack elements. The database 
communicates with these libraries through an external non-Oracle Database process 
that is spawned bv a background process called FMON. FMON is responsible for 
managing the mapping information, Oracle provides a PL/SQL package, 
DBMS_STOEAGE_MAP, that vou use to invoke mapping operations that populate the 
mapping views. 

Note: The file mapping interface is not available on Windows 
platforms. 

How the Oracle Database File Mapping Interface Works 

This section describes the components of the Oracle Database file mapping interface 
and how the interface works. It contains the following topics: 

■ Components of File Mapping 

■ Mapping Structures 

■ Example of Mapping Structures 

■ Configuration ID 

Components of File Mapping 

The following figure shows the components of the file mapping mechanism. 
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Figure 13-1 Components of File Mapping 
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The following sections briefly describes these components and how they work 
together to populate the mapping views: 

. FMON 

. External Process (FMPUTL) 

■ Mapping Libraries 

FMON FMON is a background process started by the database whenever the 
FILE_MAPPING initialization parameter is set to TRUE. FMON is responsible for: 

■ Building mapping information, which is stored in the SGA. This information is 
composed of the following structures: 

- Files 

- File system extents 

- Elements 

- Sub elements 

These structures are explained in "Mapping Structures" on page 13-18. 

■ Refreshing mapping information when a change occurs because of: 

- Changes to datafiles (size) 

- Addition or deletion of datafiles 

- Changes to the storage configuration (not frequent) 

■ Saving mapping information in the data dictionan' to maintain a view of the 
information that is persistent across startup and shutdown operations 

■ Restoring mapping information into the SGA at instance startup. This avoids the 
need for a potentiallv expensive complete rebuild of the mapping information on 
every instance startup. 

You help control this mapping using procedures that are invoked with the 

DBMS_STORAGE_MAP package. 

External Process (FMPUTL) FMON spawns an external non-Oracle Database process 
called FMPUTL, that communicates directly with the vendor supplied mapping 
hbraries. This process obtains the mapping information through all levels of the I/O 
stack, assuming that mapping libraries exist for all levels. On some platforms the 
external process requires that the SETUID bit is set to ON because root privileges are 
needed to map through all levels of the I/O mapping stack. 
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The external process is responsible for discovering the mapping hbraries and 
dynamically loading them into its address space. 

Mapping Libraries Oracle Database uses mapping libraries to discover mapping 
information for the elements that are owned by a particular mapping library. Through 
these mapping libraries information about individual I/O stack elements is 
communicated. This information is used to populate dynamic performance views that 
can be queried bv users. 

Mapping libraries need to exist for all levels of the stack for the mapping to be 
complete, and different libraries mav own their own parts of the I/O mapping stack. 
For example, a VERITAS VxVM library would own the stack elements related to the 
VERITAS Volume Manager, and an EMC hbrary would own all EMC storage specific 
layers of the I/O mapping stack. 

Mapping libraries are vendor supplied. However, Oracle currentiv supplies a 
mapping library for EMC storage. The mapping libraries available to a database server 
are identified in a spiecial file named filemap.ora. 

Mapping Structures 

The mapping structures and the Oracle Database representation of these structures are 
described in this section. You will need to understand this information in order to 
interpret the information in the mapping views. 

The following are the primary structures that compose the mapping information: 

■ Files 

A file mapping structure provides a set of attributes for a file, including file size, 
number of file system extents that the file is composed of, and the file type. 

■ File system extents 

A fUe system extent mapping structure describes a contiguous chunk of blocks 
residing on one element. This includes the device offset, the extent size, the file 
offset, the type (data or parit;'), and the name of the element where the extent 
resides. 



Note: File system extents are not the same as Oracle Database 
extents. File svstem extents are physical contiguous blocks of data 
written to a device as managed by the file system, Oracle Database 
extents are logical structures managed by the database, such as 
table space extents. 



■ Elements 

An element mapping structure is the abstract mapping structure that describes a 
storage component within the I/O stack. Elements may be mirrors, stripes, 
partitions, RAID5, concatenated elements, and disks. These structures are the 
mapping building blocks, 

■ Sub elements 

A subelement mapping structure describes the link between an element and the 
next elements in the I/O mapping stack. This structure contains the subelement 
number, size, the element name where the subelement exists, and the element 
offset. 

All of these mapping structures are illustrated in the following example. 
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Example of Mapping Structures 

Consider an Oracle Database which is composed of two data files X and Y. Both files X 
and Y reside on a file system mounted on vokime A, File X is composed of two extents 
wfhile file Y is composed of only one extent. 

The two extents of File X and the one extent of File Y both map to Element A. Element 
A is striped to Elements B and C. Element A maps to Elements B and C bv way of 
Siibelements BO and CI, respectively. 

Element B is a partition of Element D (a physical disk), and is mapped to Element D by 
way of subelement DO. 

Element C is mirrored over Elements E and F (both phvsical disks), and is mirrored to 
those physical disks bv way of Subelements EO and Fl, respectively. 

All of the mapping structures are illustrated in Figure 13-2. 



Figure 13-2 Illustration of Mapping Structures 
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Note that the mapping structures represented are sufficient to describe the entire 
mapping information for the Oracle Database instance and consequentlv to map every 
logical block within the file into a (element name, element offset) tuple (or more in 
case of mirroring) at each level within the I/O stack. 

Configuration ID 

The configuration ID captures the version information associated with elements or 
files. The vendor library provides the configuration ID and updates it whenever a 
change occurs. Without a configuration ID, there is no wav for the database to tell 
whether the mapping has changed. 

There are two kinds of configuration IDs: 
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■ Persistent 

These coniiguration EDs are persistent across instance shutdown 

■ Non-persistent 

Ttie configuration IDs are not persistent across instance shutdown. The database is 
only capable of refreshing the mapping information while the instance is up. 

Using the Oracle Database File lUlapping Interface 

This section discusses how to use the Oracle Database file mapping interface. It 
contains the following topics: 

■ Enabling File Mapping 

. Using the DBMS_STORAGE_MAP Package 

■ Obtaining Information from the File Mapping View^s 

Enabling File Mapping 

The following steps enable the file mapping feature: 

1. Ensure that a valid filemap. era file exists In the /opt/ORCLfmap/protl_32/etc 
directorv for 32-bit platforms, or in the /opt/ORCLfmap/protl_64/etc directory 
for 64-bit platforms. 



Caution: While the format and content of the filemap, ora file is 
discussed here, it is for informational reasons only. The filemap. ora 
file is created by the database when your system is installed. Until 
such time that vendors supplv there own libraries, there will be 
onlv one entrv in the filemap. ora file, and that is the 
Oracle-supplied EMC librarv. This file should be modified 
manually by uncommenting this entry ont^ if an EMC Symmetrix 
array is available. 

The filemap. ora file is the configuration file that describes all of the available 
mapping libraries. FMON requires that a filemap. ora file exists and that it points 
to a valid path to mapping libraries. Otherwise, it will not start successfullv. 

The following row needs to be included in filemap. ora for each library: 

H'h=vendor_n^nie : nia.pping_l ihr^j:y_pa.th 

where: 

■ vendor_namc should be Oracle for the EMC Symmetric library 

■ iiiapping_!ibranj_patli Is the full path of the mapping hbrary 

Note that the ordering of the libraries in this file is extremely important. The 
hbraries are queried based on their order in the configuration file. 

The file mapping service can be even started even if no mapping libraries are 
available. The filemap. ora file still needs to be present even though it is empt\'. In 
this case, the mapping service is constrained in the sense that new mapping 
information cannot be discovered. Only restore and drop operations are allowed 
in such a configuration. 



2. Set the FILE_MAPPING initialization parameter to TRUE. 
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The instance does not have to be shut down to set this parameter. You can set it 
using the following ALTER SYSTEM statement: 

ALTER SYSTEM SET FILE_HAPPIHG=TRUE; 

3. Invoke the appropriate DBMS_STORAGE_MAP mapping procedure. You have two 
options: 

■ In a cold startup scenario, the Oracle Database is just started and no mapping 
operation has been invoked vet. You execute the 

DBMS_STOEAGE_MAP .MAP_ALL procedure to build the mapping information 
for the entire I/O subsystem associated with the database. 

■ In a warm start scenario where the mapping information is already built, vou 
have the option to invoke the DBMS_STORAGE_MAP . MAP_SAVE procedure to 
save the mapping information in the data dictionary. (Note that this procedure 
is invoked in DBMS_STORAGE_]y[AP .]y[AP_ALL ( ) by default.) This forces all of 
the mapping information in the SGA to be flushed to disk. 

Once you restart the database, use DBMS_STORAGE_MAP .RESTORE ( ) to 
restore the mapping information into the SGA, If needed, 
DBMS_STORAGE_MAP .MAP_ALL ( ) can be called to refresh the mapping 
information. 

Using the DBMS_STORAGE_MAP Package 

The DBMS_STGRAGE_MAP package enables vou to control the mapping operations. 
The various procedures available to you are described in the following table. 



Procedure 


Use to: 


MAP_OBJECT 


Build the mapping information for the database object 
identified by object name, owner, and type 


MAP_ELEMEHT 


Build mapping information for the specified element 


MAP_FILE 


Build mapping information for the specified filename 


MAP_ALL 


Build entire mapping information for all types of database files 
(excluding archive logs) 


DROP_ELEMENT 


Drop the mapping information for a specified element 


DROP_FILE 


Drop the file mapping information for the specified filename 


DROP_ALL 


Drop all mapping information in the SGA for this instance 


SAVE 


Save into the data dictionary the required information needed 

to regenerate the entire mapping 


RESTORE 


Load the entire mapping information from the data dictionary 
into the shared memory of the instance 


LOCK_MAP 


Lock the mapping information in the SGA for this instance 


UNLOCK_MAP 


Unlock the mapping information in the SGA for this instance 



See Also: 



Oracle Database PL/SQL Packages and T^pes Reference for a 
description of the DBMS_STORAGE_MAP package 

"File Mapping Examples" on page 13-23 for an example of 
using the DBMS_STORAGE_MAP package 
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Obtaining Information from tfie File Mapping Views 

Mapping information generated bv DBMS_STORAGE_MAP package is captured in 
dynamic performance views. Brief descriptions of these views are presented here. 



View 



Description 



VSMAP_LIBRARY Contains a list of all mapping libraries that have been 

dynamically loaded by the external process 



VSMAP_FILE 



Contains a list of all file mapping structures in the shared 
memory of the instance 



VSMAP_FILE_EXTEHT 



Contains a list of all file system extent mapping structures in 
the shared memorv of the instance 



VSMAP_EI,EMENT 



Contains a list of all element mapping structures in the SGA of 
the instance 



V$MAP_EXT_ELEMEHT 
VSMAP_SUBELEMEHT 

VSMAP_C0MP_LI3 T 

VSMAP_FILE_IO_S TACK 



Contains supplementary information for all element mapping 

Contains a list of all subelement mapping structures in the 
shared memory of the instance 

Contains supplementary information for all element mapping 
structures. 

The hierarchical arrangement of storage containers for the file 
displayed as a series of rows. Each row represents a level in 
the hierarchy 



See Also: Oracle Database Referenee for a complete description of 
the dynamic performance views 

However, the information generated by theDBMS_STORAGE_MAP .MAP_OBJECT 
procedure is captured in a global temporary table named MAP_OBJECT. This table 
displays the hierarchical arrangement of storage containers for objects. Each row in the 
table represents a leyel in the hierarchy. A description of the M6.P_0BJECT table 
follows. 



Column 



Datatype 



Description 



OBJECTJAME VARCHAR2 ( 2 DOO ) 

OBJECT_OWHER VARCHAR2 ( 2 000 ) 

OBJECT_TYPE VARCHAR2 ( 2 000 ) 

FILE_MAP_IDX HUMBER 

DEPTH NUMBER 

ELEM_IDX NUMBER 

CU SIZE NUMBER 



STRIDE 



HUM CU 



NUMBER 



NUMBER 



Name of the object 

Owner of the object 

Object type 

File index (corresponds to FILE_MAP_IDX in 
VSMAP_FILE) 

Sement depth within the I/O stack 

Index corresponding to element 

Contiguous set of logical blocks of the file, in HKB 
(half KB) units, that is resident contiguously on the 
element 

Number of HKB between contiguous units (CU) in 
the file that are contiguous on this element Used 

in RAIDS and striped files. 

Number of contiguous units that are adjacent to 
each other on this element that are separated by 

STRIDE HKB in the file. In RAIDS, the number of 
contiguous units also include the parity stripes. 
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Column 



Datatype 



Description 



ELEM_OFFSET 
FILE OFFSET 



DATA_TYPE 
PARITY POS 



HUMBER 
HUMBER 



VARCHAR2 (2 000) 
HUMBER 



PARITY PERIOD HUMBER 



Element offset in HKB units 

Offset in HKB units from the start of the file to the 

first byte of the contiguous units 

Datatype (DATA, PARITY, or DATA AMD PARITY) 

Position of the parity Only for RAIDS. This field is 
needed to distinguish the parity from the data 
part. 

Parity period. Only for RAIDS. 



File Mapping Examples 



The following examples illustrates some of the powerful capabilities of the Oracle 
Database file mapping feature. This includes: 

■ The ability to map ail the database files that span a particular device 

■ The ability to map a particular file into its corresponding devices 

■ The abilitv to map a particular database object, including its block distribution at 
all levels within the I/O stack 

Consider an Oracle Database instance which is composed of two datafiles: 

t_dbl . f 

t_db2 . f 

These files are created on a Solaris UFS file system mounted on a VERITAS VxVM host 
based striped volume, /dev/vx/dsk/ipf dg/ipf -voll, that consists of the 
following host devices as externalized from an EMC Symmetrix array: 

■ /dev/vx/rdmp/c2tld0s2 

■ /dev/vx/rdmp/c2tldls2 

Note that the following examples require the execution of a MAP_ALL ( ) operation. 

Example 1 : Map All Database Files that Span a Device 

The following query returns all Oracle Database files associated with the 
/dev/vx/rdnip/c2tldls2 host device: 

SELECT UMIQHE me.EI^EM_NAME, mf .FILE_HAME 

FROM VSMAP_FILE_IO_STACK fs, VSMAP_FILE mf, VSMAP_ELEHENT me 

'rfHERE mf .FILE_MAP_IDX = fs .FILE_MAP_IDX 

AND me.EI^EM_IDX = fs.ELEM_IDX 

AND me . EI^EM_NAME = 7dev/vx/rdnp/c2tldls2 ' ; 



The query results are: 

ELEM HAME 



FILE HAME 



/dev/vx/rdmp/c2tldls2 
/dev/vx/rdrap/c2tldls2 



/oracle/dbE/t_dbl.f 
/oracle/dbE/t_db2.f 



Example 2: Map a File into Its Corresponding Devices 

The following querv displays a topological graph of the /oracle/dbs/ t_dbl . f 
datafile: 
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WITH fv AS 

{SELECT FILE_MAP_IDX, FII£_HME FROM VSMAP_FILE 
WHERE FII£_HAME = 7oracle/dbs/t_dbl .f ) 
SELECT fv.FILE_HME, LPAD ( ' ', 4 ' (LEVEL -1)) || el.ELEM_HAME ELEHJME 
FROM VSMftP_SHBELEMEHT sb, VSMAP_ELEMENT el, fv, 

{SELECT UHIQUE ELEM_IDX FROM V$MAP_FILE_IO_STACK io, fv 
WHERE io.FILE_MAP_IDX = fv.FILE_MAP_IDX) fs 
WHERE el.ELEM_IDX = sb.CHILD_IDX 
MD fs.ELEM_IDX = el.ELEM_IDX 
START WITH sb . PARENT_IDX IH 
{SELECT DISTINCT ELEMJDX 
FROM V5MAP_FILE_EXTENT fe, fv 
WHERE fv.FILE_MAP_IDX = fe.FILE_MAP_IDX) 
CONNECT BY PRIOR sb.CHILD_IDX = sb . PARENT_IDX ; 



The resulting topological graph is: 

FILE NAME ELEM HAME 



/oracle/dbE/t_dbl . f _syni_plex_/d.ev/vx/rdsk/ipfd.g/ipf-voll_-l_-l 

/oracle/dbE/t_dbl . f _syiiL_subdi3k_/dev/v)(/rdsk/ipfdg/ipf-voll_0_0_0 

/oracle/dbs/t_dbl . f /dev/vx/rdinp/c2tld0s2 

/oracle/dbE/t_dbl.f _syiii_symdev_000183600407_OOC 

/oracle/dbE/t_dbl.f _syni_hyper_000183500407_OOC_0 

/oracle/dbE/t_dbl.f _syiii_hyper_000183500407_OOC_l 

/oracle/dbE/t_dbl . f _syin_subdi3k_/dev/vx/rdsk/ipfdg/ipf-voll_0_l_0 

/oracle/dbE/t_dbl.f /dev/vx/rdinp/c2tldls2 

/oracle/dbE/t_dbl.f _S¥ni_S¥nidev_000183600407_OOD 

/oracle/dbE/t_dbl.f _syni_hyper_000183500407_OOD_0 

/oracle/dbE/t_dbl.f _syni_hyper_000183500407_OOD_l 

Example 3: Map a Database Object 

This example displays the block distribution at all levels within the I/O stack for the 

scott. bonus table. 

A MAP_OBJECT { ) operation must first be executed as follows: 

EXECUTE DBMS_STORAGE_MftP.MftP_OBJECT{ 'BONUS' , 'SCOTT' , 'TABLE') ; 

The query is as follows: 

SELECT io . OBJECT_MAME o_naine, io.OBJECT_OWMER o_owner, io .OBJECT_T¥PE o_type, 
mf .FILE_NAME, me . ELEM_HftME , io. DEPTH, 
{SUM(io.CU_SIZE • (io.HUH_CU - DECODE{io.PARITY_PERIOD, 0, 0, 

TRUHC(io.NnM_CU / io.PARIT¥_PERIOD) ) ) } / 2) o_size 
FROM MAP_OBJECT io, VSMftP_ELEMEHT me, V5MAP_FILE mf 
WHERE io . OBJECT_HAME = 'BONUS' 
AND io . 0BJECT_01NER = 'SCOTT' 
AND io . OBJECT_TYPE = 'TABLE' 
AND me.ELEM_IDX = io.ELEMJDX 
AND mf.FILE_MAP_IDX = io.FILE_MAP_IDX 
GROUP BY io.ELEM_IDX, io .FILE_MftP_IDX, me . ELEM_HAME , mf .FILE_NAME, io. DEPTH, 

io.OBJECT_HAME, io .OBJECT_OMNER, io . OBJECT_TYPE 
ORDER BY io. DEPTH; 

The following is the result of the query. Note that the o_size column is expressed in 
KB. 

0_HAME 0_OWNER 0_TYPE FILE_MAME ELEM_NAHE DEPTH 0_SIZE 

BOMUS SCOTT TABLE /oraole/dbs/t_dbl .f /dev/vx/dsk/ipfdg/ipf-voll 2 



13-24 Oracle Database Administrator's Guide 



Datafiles Data Dictionary Views 



BONUS 


SCOTT 


TftBI£ 


/oracle/dbs/t_iibl 


f 


BONUS 


SCOTT 


TABI£ 


/oracle/dbs/t_<ibl 


f 


BONUS 


SCOTT 


TftBI£ 


/oracle/dbs/t_<ibl 


f 


BOHUS 


SCOTT 


TftBLE 


/oracle/dbs/t_dbl 


f 


BOIUS 


SCOTT 


TftBLE 


/oracle/dbs/t_dbl 


f 


BOHUS 


SCOTT 


TftBI.E 


/oracle/dbs/t_dbl 


f 


BOHUS 


SCOTT 


TftBI.E 


/oracle/dbs/t_dbl 


f 


BOHUS 


SCOTT 


TftBI.E 


/oracle/dbs/t_dbl 


f 


BOHUS 


SCOTT 


TftBLE 


/oracle/dbs/t_dbl 


f 


BONUS 


SCOTT 


TftBLE 


/oracle/dbs/t_dbl 


f 


BONUS 


SCOTT 


TftBI£ 


/oracle/dbs/t dbl 


f 



_EyiiL_plex_/dev/vx/rdEk/ipf 1 
pdg/if-voll_-l_-l 

_syiii_s"ubdisk_/dev/vx/rdsk:/ 2 
ipfdg/ipf-voll_0_l_0 

_syiii_s"ubdisk_/dev/vx/rdsk:/ipE 2 
dg/ipf-voll_0_2_0 

/dev/vx/rdmp/c2tldlE2 3 

/dev/vx/rdmp/c2tld2E2 3 

_sym_synidev_000183500407_OOD 4 

_syin_Eymdev_000183500407_OOE 4 

_syin_tiyper_000183600407_OOD_0 5 

_sym_tiyper_0001836004 07_OOD_l 5 

_syin_hyper_0001836004 07_OOE_0 6 

_syiii_hyper_0001836004 07_OOE_l 6 



20 
12 



12 

8 

12 



12 
12 



Datafiles Data Dictionary Views 



The following data dictioiiarv views provide useful information about the datafiles of 
a database: 



View 



Description 



DBA DATA FILES 



DBA_EXTEHTS 
USER EXTEHTS 



Provides descriptive information about each datafile, 
including the tablespace to which it belongs and the file ID. 
The file ID can be used to join with other views for detail 
information. 

DBA view describes the extents comprising all segments in the 
database. Contains the file ID of the datafile containing the 
extent. USER view describes extents of the segments belonging 
to objects owned by the current user. 



DBA_FREE_S PACE 
DSER_FREE_S PACE 

' VS DATAFILE 



DBA view lists the free extents in all tablespaces. Includes the 
file ID of the datafile containing the extent. USER view lists the 
free extents in the tablespaces accessible to the current user 

Contains datafile information from the control file 



VS DATAFILE_HEADER 



Contains information from datafile headers 



This example illustrates the use of one of these views, V$DATAFILE. 

SELECT NME, 
FILE#, 
STATUS , 

CHECKPOIHT_CHMGEtt "CHECKPOINT" 
FROM VSDATAFILE; 



NME 



/uOl/oracle/rbdbl/systemOl.dbf 

/u02/oracle/rbdbl/temp01.dbf 

/u02/oracle/rbdbl/userE03.dbf 



FILE* STATUS CHECKPOINT 



1 


SYSTEM 


3839 


2 


OHLINE 


3782 


3 


OFFLIHE 


3782 



FILE# lists the file number of each datafile; the first datafile in the SYSTEM tablespace 
created with the database is always file 1, STATUS lists other information about a 
datafile. If a datafile is part of the SYSTEM tablespace, its status is SYSTEM (unless it 
requires recovery). If a datafile in a non-SYSTEM tablespace is online, its status is 
ONLINE. If a datafile in a non-SYSTEM tablespace is offline, its status can be either 
OFFLINE or RECOVER, CHECKPOINT Usts the final SCN (system change number) 
written for the most recent checkpoint of a datafile. 
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See Also: Oracle Database Reference for complete descriptions of 
these views 
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Managing Undo 



Beginning with Release lli;, for a default installation, Oracle Database aiitomaticallv 
manages undo. There is t\'picallv no need for DBA intervention. However, if your 
installation uses Oracle Flashback operations, vou mav need to perform some undo 
management tasks to ensure the success of these opertitions. 

In this chapter: 

What Is Undo? 

Introduction to Automatic Undo Management 

Setting the Minimum Undo Retention Period 

Sizing a Fixed-Size Undo Tablespace 

Managing Undo Tablespaces 

Migrating to Automatic Undo Management 

Undo Space Data Dictionary Vievifs 

See Also: Chapter 15, "Using Oracle-Managed Files"for 
information about creating an undo tablespace whose datafiles are 
both created and managed by Oracle Database. 



What Is Undo? 



Oracle Database creates and manages information that is used to roll back, or undo, 
changes to the database. Such information consists of records of the actions of 
transactions, primarily before they are committed. These records are collectively 
referred to as undo. 

Undo records are used to: 

Roll back transactions when a ROLLBACK statement is issued 

Recover the database 

Provide read consistency 

Analyze data as of an earlier point in time by using Oracle Flashback Quer\' 

Recover from logical corruptions using Oracle Flashback features 

When a ROLLBACK statement is issued, undo records are used to undo changes that 
were made to the database by the uncommitted transaction. During database recovery, 
undo records are used to undo anv uncommitted changes applied from the redo log to 
the datafiles. Undo records provide read consistency by maintaining the before image 
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of the data for users who are accessing the data at the same time that another user is 
changing it. 

Introduction to Automatic Undo IVIanagement 

This section introduces the concepts of Automatic Undo Management and discusses 
the following topics: 

■ Overview of Automatic Undo Management 

■ About the Undo Retention Period 



Overview of Automatic Undo Management 



Oracle provides a fully automated mechanism, referred to as automatic undo 
management, for managing undo information and space. With automatic undo 
management, the database manages undo segments in an undo tablespace. Beginning 
with Release 11^^, automatic undo management is the default mode for a newlv 
installed database. An auto-extending undo tablespace named UNDOTBSl is 
automatically created when you create the database with Database Configuration 
Assistant (DBCA). 

An undo tablespace can also be created explicitly. The n\ethods of creating an undo 
tablespace are explained in "Creating an Undo Tablespace" on page 14-8. 

When the instance starts, the database autom.atically selects the first avaUable undo 
tablespace. If no undo tablespace is available, the instance starts without an undo 
tablespace and stores undo records in the SYSTEM tablespace. This is not 
recommended, and an alert message is written to the alert log file to warn that the 
system is running without an undo tablespace. 

If the database contains multiple undo tablespaces, vou can optionally specify at 
startup that vou want to use a specific undo tablespace. This is done by setting the 
UHDO_TABLE SPACE initialization parameter, as shown in this example: 

™dO_TABLESPACE = imdotbs_01 

If the tablespace specified in the initialization parameter does not exist, the STARTUP 
command fails. The UNDO_TABLE SPACE parameter can be used to assign a specific 
undo tablespace to an instance in an Oracle Real Application Clusters environment. 

The database can also run in manual undo management mode. In this mode, undo space 
is managed through rollback segments, and no undo tablespace is used. 

Note: Space management for rollback segments is complex. Oracle 
strongly recommends leaving the database in automatic undo 
management mode. 



The following is a summary of the initialization parameters for undo management: 

Initialization Parameter Description 

UMDO_MAHAGEMEMT If AUTO or null, enables automatic undo management. If 

MANUAL, sets manual undo management mode. The default is 

AUTO. 
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Initialization Parameter Description 



'DMDO_TABLE SPACE Optional, and valid onlv in automatic undo management 

mode. Specifies the name of an undo tablespace. Use only 
when the database has multiple undo tablespaces and you 
want to direct the database instance to use a particular undo 

tablespace. 



When automatic undo management is enabled, if the initialization parameter file 
contains parameters relating to manual undo management, they are ignored. 

Note: Earlier releases of Oracle Database default to manual undo 
management mode. To change to automatic undo management, you 
must first create an undo tablespace and then change the 
UWriO_MaNAGEMENT initialization parameter to AUTO. If your Oracle 
Database is release 9/ or later and you want to change to automatic 
undo management, see Oracle Database Upgrade Guide for instructions. 

A null UNDO_MANAGEMENT initialization parameter defaults to 
automatic undo management mode in Release llg and later, but 
defaults to manual undo management mode in earlier releases. You 
must therefore use caution when upgrading a previous release to 
Release llg. Oracle DatniuKC Upgrade Guide describes the correct 
method of migrating to automatic undo management mode, including 
information on how to size the undo tablespace. 



See Also: Oracle Database Reference for complete descriptions of 
initialization parameters used in undo management 



About the Undo Retention Period 



After a transaction is committed, undo data is no longer needed for rollback or 
transaction recover}' purposes. However, for consistent read purposes, long-running 
queries mav require this old undo information for producing older images of data 
blocks. Furthermore, the success of several Oracle Flashback features can also depend 
upon the availability of older undo information. For these reasons, it is desirable to 
retain the old undo information for as long as possible. 

When automatic undo management is enabled, there is always a current undo 
retention period, which is the minimum amount of time that Oracle Database 
attempts to retain old undo information before overwriting it. Old (committed) undo 
information that is older than the current undo retention period is said to be expired 
and its space is available to be overwritten bv new transactions. Old undo information 
with an age that is less than the current undo retention period is said to be unexpired 
and is retained for consistent read and Oracle Flashback operations. 

Oracle Database automatically tunes the undo retention period based on undo 
tiiblespace size and svstem activitv. You can optionally specif}" a minimum undo 
retention period (in seconds) by setting the UNDO_RETENTIOH initialization 
parameter. The exact impact this parameter on undo retention is as follows: 

■ The UNDO_RETENTION parameter is ignored for a fixed size undo tablespace. The 
database always tunes the undo retention period for the best possible retention, 
based on system activity and undo tablespace size. See "Automatic Tuning of 
Undo Retention" on page 14-4 for more information. 
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■ For an undo tablespace with the AUTOEXTEND option enabled, the dat.ibase 
attempts to honor the minimum retention period specified bv lINDO_EETEWTIOW. 
When space is low, instead of overwriting unexpired undo information, the 
tablespace auto-extends. If theMAXSIZE clause is specified for an auto-extending 
undo tablespace, when the maximum size is reached, the database mav begin to 
overwrite unexpired undo information. The UNDOTBSl tablespace that is 
automaticallv created bv DBCA is auto-extending. 

Automatic Tuning of Undo Retention 

Oracle Database automaticallv tunes the undo retention period based on how the 
undo tablespace is configured, 

■ If the undo tablespace is configured with the AUTOEXTEND option, the database 
dynamicallv tunes the undo retention period to be somewhat longer than the 
longest-running active querv on the system. However, this retention period may 
be insufficient to accommodate Oracle Flashback operations. Oracle Flashback 
operations resulting in snapshot too old errors are the indicator that you must 
intervene to ensure that sufficient undo data is retained to support these 
operations. To better accommodate Oracle Flashback features, you can either set 
the UNDO_RETENTION parameter to a value equal to the longest expected Oracle 
Flashback operation, or you can change the undo tablespace to fixed size. 

■ If the undo tablespace is fixed size, the database dynamically tunes the undo 
retention period for the best possible retention for that tablespace size and the 
current system load. This best possible retention time is typically significantly 
greater than the duration of the longest-running active query. 

If you decide to change the undo tablespace to fixed-size, you must choose a 
tablespace size that is sufficiently large. If you choose an undo tablespace size that 
is too small, the following two errors could occur: 

■ DML could fail because there is not enough space to accommodate undo for 
new transactions. 

■ Long-running queries could fail with a snapshot too old error, which 
means that there was insufficient undo data for read consistency. 

See "Sizing a Fixed-Size Undo Tablespace" on page 14-6 for more information. 

Note: Automatic tuning of undo retention is not supported for LOBs. 
This is because undo information for LOBs is stored in the segment 
itself and not in the undo tablespace. For LOBs. the database attempts 
to honor the minimum undo retention period specified bv 
UWDO_RETEWTIOW. However, if space becomes low, unexpired LOB 
undo information may be overwritten. 



See Also: "Setting the Minimum Undo Retention Period" on 
page 14-6 

Retention Guarantee 

To guarantee the success of long-running queries or Oracle Flashback operations, you 
can enable retention guarantee. If retention guarantee is enabled, the specified 
minimum undo retention is guaranteed; the database never overwrites unexpired 
undo data even if it means that transactions fail due to lack of space in the undo 
tablespace. If retention guarantee is not enabled, the database can overwrite unexpired 
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undo when space is low. thus lowering the undo retention for the svstem. This option 
is disabled by default, 

WARNING: Enabling retention guarantee can cause multiple DML 
operations to fail. Use with caution. 

You enable retention guarantee by specifying the RETENTION GUARANTEE clause for 
the undo tablespace when you create it with either the CREATE DATABASE or CREATE 
DNDO TABLESPACE statement. Or, you can later specify this clause in an ALTER 
TABLESPACE statement. You disable retention guarantee with the RETENTION 

NO GUARANTEE clause. 

You can use the DBA_TABLE SPACES view to determine the retention guarantee setting 
for the undo tablespace, A column named RETENTION contains a value of 
GUARANTEE, NOGUARANTEE, or NOT APPLY, where NOT APPLY is used for tablespaces 
other than the undo tablespace. 

Undo Retention Tuning and Aiert Tiireshoids 

For a fixed-size undo tablespace, the database calculates the best possible retention 
based on database statistics and on the size of the undo tablespace. For optimal undo 
management, rather than tuning based on 100% of the tablespace size, the database 
tunes the undo retention period based on 85''u of the tablespace size, or on the warning 
alert threshold percentage for space used, whichever is lower, (The warning alert 
threshold defaults to 85%, but can be changed.) Therefore, if vou set the warning alert 
threshold of the undo tablespace below 85%, this mav reduce the tuned size of the 
undo retention period. For more information on tablespace alert thresholds, see 
"Managing Tablespace Alerts" on page 17-1, 

Traclting tlie Tuned Undo Retention Period 

You can determine the current retention period by querving the 
TUMED_UNDORETENTION column of the VS UNDO STAT view. This view contains one 
row for each 10-minute statistics collection interval over the last 4 days, (Beyond 4 
days, the data is available in the DBA_HIST_UNDOSTAT view.) 
TUNED_UNDORE TENT ION is given in seconds. 

select to_ctiar(begiii_time, ' DD-MON-RR HH24:MI ' ) beginjime. 
to_char(eiid_tme, 'DD-MOl-ES HH24 :MI ' | endjime, tiined_ijndoreterition 
from vSundostat order by end_tims; 

BEGIN_TIME END_TIME TUHED_UHDOHETENTION 

04-FEB-05 00:01 04-FEB-05 00:11 12100 

07-FEB-05 23:21 07-FEB-05 23:31 85700 

07-FEB-05 23:31 07-FEB-05 23:41 85700 

07-FEB-05 23:41 07-FEB-05 23:51 85700 

07-FEB-05 23:51 07-FEB-05 23:52 85700 

575 rows selected. 

See Oracle Database Reference for more information about VSUNDOSTAT. 
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Setting the Minimum Undo Retention Period 

You specify the ininimiLm undo retention period (in seconds) by setting tlie 
UWr>0_RETEWTIOW initiiilization parameter As described in "About tiie Undo 
Retention Period" on page 14-3, the current undo retention period may be 
automatically tuned to be greater than UWDO_RETENTIOW, or, unless retention 
guarantee is enabled, less than UNDO_RETENTION if space in the undo tablespace is 
low. 

To set the minimum undo retention period: 

■ Do one of the following: 

- Set UNDO_RETENTI0N in the initialization parameter file. 

UMDO_HETENTI01 = 1800 

Change UWr)0_RETENTIOW at any time using the ALTER SYSTEM statement: 

ALTER SYSTEM SET UNDO_HETENTION = 2400; 

The effect of an lINI>0_RETEWTIOW parameter change is immediate, but it can only be 
honored if the current undo tablespace has enough space. 

Sizing a Fixed-Size Undo Tablespace 

If vou have decided on a fixed-size undo tablespace, the Undo Advisor can help vou 
estimate needed capacit}'. You can access the Undo Advisor through Enterprise 
Manager or through the DBMS_ADVISOR PL /SQL package. Enterprise Manager is the 
preferred method of accessing the advisor For more information on using the Undo 
Advisor through Enterprise Manager, see Oracle Database 2 Da\.j DBA. 

The Undo Advisor relies for its analvsis on data collected in the Automatic Workload 
Repository (AWR), It is therefore important that the AWR have adequate workload 
statistics available so that the Undo Advisor can make accurate recommendations. For 
newly created databases, adequate statistics may not be avaUable immediately. In such 
cases, an auto-extending undo tablespace can be used. 

An adjustment to the collection interval and retention period for AWR statistics can 
affect the precision and the type of recommendations that the advisor produces. See 
Oracle Database Performance Tuning Guide for more information. 

To use the Undo Advisor, you first estimate these two values: 

■ The length of your expected longest running query 

After the database has completed a workload cvcle, vou can view the Longest 
Running Querv field on the System Activity subpage of the Automatic Undo 
Management page, 

■ The longest interval that you will require for Oracle Flashback operations 

For example, if vou expect to run Oracle Flashback queries for up to 48 hours in 
the past, your Oracle Flashback requirement is 48 hours. 

You then take the maximum of these two values and use that value as input to the 
Undo Advisor, 

Running the Undo Advisor does not alter the size of the undo tablespace. The advisor 
just returns a recommendation. You must use ALTER DATABASE statements to change 
the tablespace datafiles to fixed sizes. 
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The following example assumes that the undo tablespace has one auto-extending 
datafile named undotbs .dbf . The example changes the tablespace to a fixed size of 
300MB. 

ALTER DATABASE DATAFILE ' /oracle/dbs/imdotbs .diif RESIZE 300H; 
ALTER DATABASE DATAFILE ' /oracle/dbs/undotbs .dbf AUTOEXTEND OFF; 



Note: If you want to make the undo tablespace fixed-size, Oracle 
suggests that vou first allow enough time after database creation to 
run a full workload, thus allowing the undo tablespace to grow to its 
minimum required size to handle the workload. Then, you can use the 
Undo Advisor to determine, if desired, how much larger to set the size 
of the undo tablespace to allow for long-running queries and Oracle 
Flashback operations. 



The Undo Advisor PL/SOL Interface 



You can activate the Undo Advisor bv creating an undo advisor task through the 
advisor framework. The following example creates an undo advisor task to evaluate 
the undo tablespace. The name of the advisor is 'Undo Advisor'. The analvsis is based 
on Automatic Workload Repository snapshots, which vou must specify by setting 
parameters START_SNAPSHOT and END_3NAP3H0T. In the following example, the 

START_SWAPSHOT is "1" and EWD_SNAPSHOT is "2". 

DECLARE 

tid NUMBER; 

tnanie VARCHAH2 (30) ; 

old HIMBER; 

BEGIN 

IlBMS_ADVISOR.CREATE_TASKCUndo Advisor' , tid, tname, 'Undo Advisor Task' ) ; 

DBMS_ADVISOR.CREATE_OBJECT[tname, 'UHDO_TBS', null, null, null, 'null', oid) ; 

DBMS_ADVISOR.SET_TASK_PARAMETER(tname, ' TARGET_OBJECTS ' , oid) ; 

IlBMS_ADVISOR.SET_TASK_PARAMETER(tname, ' START_SHAPSHOT' , 1) ; 

IlBMS_ADVISOR.SET_TASK_PARAMETER(tname, ' END_SHAPSHOT ' , 2) ; 

DBMS_ADVISOR. SET_TASK_PARAMETER (name, ' INSTAUCE ' , 1 } ; 

DBMS_ADVISOR.execute_task(tnanie] ; 

end; 
/ 

After you have created the advisor task, vou can view the output and 
recommendations in the Automatic Database Diagnostic Monitor in Enterprise 
Manager, This information is iilso available in the DBA_ADVISOR_'^ data dictionary 
views. 

See Also: 

■ "Using the Segment Advisor" on page 17-16 for an example of 
creating an advisor task for a different advisor 

■ Oracle Database Reference for information about the 

DBA ADVISOR * data dictionarv vievi's 



Managing Undo Tablespaces 



This section describes the various steps involved in undo tablespace management and 
contains the following sections: 

■ Creating an Undo Tablespace 
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Altering an Undo Tablespace 
Dropping an Undo Tablespace 
Switcliing Undo Tablespaces 
Establisliing User Quotas for Undo Space 
Undo Space Data Dictionary Views 



Creating an Undo Tablespace 



AlttioLLgli Database Configuration Assistant (DBCA) aiitomaticallv creates an undo 
tablespace for new installations of Oracle Database Release 11^, there may be 
occasions when you want to manually create an undo tablespace. 

There are two methods of creating an undo tablespace. The first method creates the 
undo tablespace when the CREATE DATABASE statement is issued. This occurs when 
you are creating a new database, and the instance is started in automatic undo 
management mode (UND0_M7iNAGEMENT = AUTO). The second method is used with 
an existing database. It uses the CREATE UNDO TABLESPACE statement. 

You carmot create database objects in an undo tablespace. It is reserved for 
system-managed undo data. 

Oracle Database enables you to create a single-file undo tablespace. Single-file, or 
bigfile, tablespaces are discussed in "Bigfile Tablespaces" on page 12-6. 

Using CREATE DATABASE to Create an Undo Tablespace 

You can create a specific undo tablespace using the UNDO TABLESPACE clause of the 

CREATE DATABASE statement 

The following statement illustrates using the UNDO TABLESPACE clause in a CREATE 
DATABASE statement The undo tablespace is named undotbs_01 and one datafile, 

/uDl/oracle/rbdbl/undoDlDl . dbf , is allocated for it. 

OtEATE DATABASE rbdbl 

CONTROLFILE REUSE 



UHDO TaSLESPACE undotbsjl DATAFILE '/uOl/oracle/rbdbl/undoOlOl.dbf ; 

If the undo tablespace cannot be created successfullv during CREATE DATABASE, the 
entire CREATE DATABASE operation fails. You must clean up the database files, 
correct the error and retry the CREATE DATABASE operation. 

The CREATE DATABASE statement also lets vou create a single-file undo tablespace at 
database creation. This is discussed in "Supporting Bigfile Tablespaces During 
Database Creation" on page 2-20. 

See Also: Oracle Database SQL Language Reference for the syntax 
for using the CREATE DATABASE statement to create an undo 
tablespace 

Using tlie CREATE UNDO TABLESPACE Statement 

The CREATE UNDO TABLESPACE statement is the same as the CREATE 
TABLESPACE statement, but the UNDO kevword is specified. The database determines 
most of the attributes of the undo tablespace, but you can specify the DATAFILE 
clause. 
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This example creates the und.otbs_0 2 undo table space with the AUTOEXTEHD option: 

CREATE UMBO TABI£SPACE undot±E_02 

DATftFILE 7-u01/oracle/rbdbl/undo0201.dbf ' SIZE 2M REUSE AUTOEXTEND OM; 

You can create more than one undo tablespace, but onlv one of them can be active at 
any one time. 

See Also: Oracle Database SQL Language Reference for the syntax 
for using the CREATE UNDO TABLESPACE statement to create an 
undo tablespace 



Altering an Undo Tablespace 



Undo tablespaces are altered using the ALTER TABLESPACE statement. However, 
since most aspects of undo tablespaces are system managed, vou need only be 
concerned with the following actions: 

Adding a datafije 

Renaming a datafile 

Bringing a datafile online or taking it offline 

Beginning or ending an open backup on a datafile 

Enabling and disabling undo retention guarantee 

These are also tlie onlv attributes you are permitted to alter 

If an undo tablespace runs out of space, or you w^ant to prevent it from doing so, vou 
can add more fUes to it or resize existing datafiles. 

The following example adds another datafile to undo tablespace undotbs_01: 

ALTER TABLESPACE undotbs_01 

ADD DATAFILE 7ii01/oracle/rbdbl/imdo0102 .dhf AUTOEXTEND OH HEXT IH 
MAXSIZE UNLIMITED; 

You can use the ALTER DATABASE . . . DATAFILE statement to resize or extend a 
datafile. 

See Also: 

■ "Changing Datafile Size" on page 13-5 

■ Oracle Database SQL Language Reference for ALTER 
TABLESPACE syntax 



Dropping an Undo Tablespace 



Use the DROP TABLESPACE statement to drop an undo tablespace. The following 
example drops the undo tablespace undotbs_0 1: 

DROP TABLESPACE imdotbs.Ol; 

An undo tablespace can only be dropped if it is not currently used bv any instance. If 
the undo tablespace contains any outstanding transactions (for example, a transaction 
died but has not yet been recovered), the DROP TABLESPACE statement fails. 
However, since DROP TABLESPACE drops an undo tablespace even if it contains 
unexpired undo information (within retention period), vou must be careful not to 
drop an undo tablespace if undo information is needed by some existing queries. 
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DROP TABLESPACE for undo tablespaces behaves like DROP 

TABLESPACE. . .INCLUDING CONTENTS. All contents of the undo tablespace are 

removed. 

See Also: Oracle Database SQL Language Reference for DROP 

TABLESPACE svntax 



Switching Undo Tablespaces 



You can switch from using one undo tablespace to another Because the 
UNDO_TABLE SPACE initialization parameter is a dynamic parameter, the ALTER 
SYSTEM SET statement can be used to assign a new undo tablespace. 

The following statement switches to a new undo tablespace: 

ALTER SYSTEM SET UHDO_TABLESPACE = "undotbs.Oa; 

Assuming undotbs_01 is the current undo tablespace, after this command 
successfully executes, the instance uses und.otb3_0 2 in place of undotb3_01 as its 
undo tablespace. 

If any of the following conditions exist for the tablespace being switched to, an error is 
reported and no switching occurs: 

■ The tablespace does not exist 

■ The tablespace is not an undo tablespace 

■ The tablespace is already being used bv another instance (in a RAC environment 
only) 

The database is online while the switch operation is performed, and user transactions 
can be executed while this command is being executed. When the switch operation 
completes successfully, all transactions started after the switch operation began are 
assigned to transaction tables in the new undo tablespace. 

The switch operation does not wait for transactions in the old undo tablespace to 
commit If there are any pending transactions in the old undo tablespace, the old undo 
tablespace enters into a PENDING OFFLINE mode (status). In this mode, existing 
transactions can continue to execute, but undo records for new user transactions 
cannot be stored in this undo tablespace. 

An undo tablespace can exist in this PENDING OFFLINE mode, even after the switch 
operation completes successfully, A PENDING OFFLINE undo tablespace cannot be 
used bv another instance, nor can it be dropped, Eventuallv, after all active 
transactions have committed, the undo tablespace automatically goes from the 
PENDING OFFLINE mode to the OFFLINE mode. From then on, the undo tablespace 
is available for other instances (in an Oracle Real Application Cluster environment). 

If the parameter value for UNDO TABLESPACE is set to " (two single quotes), then the 
current undo tablespace is switched out and the next available undo tablespace is 
switched in. Use this statement with care because there mav be no undo tablespace 
available. 

The following example unassigns the current undo tablespace: 

ALTER SYSTEM SET UNDO TABLESPACE = ' ' ; 
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Establishing User Quotas for Undo Space 

The Oracle Database Resource Manager can be used to establish user quotas for undo 
space. The Database Resource Manager directive UNDO_POOL allows DBAs to limit the 
amount of undo space consumed by a group of users (resource consumer group). 

You can specify an undo pool for each consumer group. An undo pool controls the 
amount of total undo that can be generated bv a consumer group. When the total undo 
generated bv a consumer group exceeds its undo limit, the current UPDATE transaction 
generating the undo is terminated. No other members of the consumer group can 
perform further updates until undo space is freed from the pool. 

When no UNDO_POOL directive is explicitly defined, users are allowed unlimited undo 
space. 

See Also: Chapter 25, "Managing Resource Allocation with 
Oracle Database Resource Manager" 

Managing Space Threshold Alerts for the Undo Tablespace 

Oracle Database also provides proactive help in managing tablespace disk space use 
bv alerting you when tablespaces run low on available space. Please refer to 
"Managing Tablespace Alerts" on page 17-1 for information on how to set alert 
thresholds for the undo tablespace. 

In addition to the proactive undo space alerts, Oracle Database also provides alerts if 
your svstem has long-running queries that cause SNAPSHOT TOO OLD errors. To 
prevent excessive alerts, the long querv alert is issued at most once every 24 hours. 
When the alert is generated, you can check the Undo Advisor Page of Enterprise 
Manager to get more information about the undo tablespace. 

Migrating to Automatic Undo Management 

If vou are currently using rollback segments to manage undo space, Oracle strongly 
recommends that you migrate your database to automatic undo management. 

For instructions, see Oracle Database Upgrade Guide. 



Undo Space Data Dictionary Views 



This section lists views that are useful for viewing information about undo space in the 
automatic undo management mode and provides some examples. In addition to views 
hsted here, you can obtain information from the views available for viewing 
tablespace and datafile information. Please refer to "Dataf iles Data Dictionary Views" 
on page 13-25 for information on getting information about those views. 

The foUowing dvnamic performance views are useful for obtaining space information 
about the undo tablespace: 

View Description 

VSUKDOSTAT Contains statistics for monitoring and tuning undo space. 

Use this view to help estimate the amount of undo space 

required for the current workload. The database also uses 
this information to help tune undo usage in the system. This 
view is meaningful only in automatic undo management 
mode. 
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View 


Description 


VSROLLSTAT 


For automatic undo management mode, information reflects 
behavior of the undo segments in the undo tablespace 


VSTRAHSACTIOR 


Contains undo segment information 


DBA_"DMDO_EXTEHTS 


Shows the status and size of each extent in the undo 
tablespace. 


DBA_HIST_UNDOS TAT 


Contains statistical snapshots of VSIIHDOSTAT information. 
Please refer to Oracle Dotabase 2 Da\j DBA for more 
information. 



See Also: Oracle Database Reference for complete descriptions of 
the views used in automatic undo management mode 

The VS UNDO STAT view is useful for monitoring the effects of transaction execution on 
undo space in the current instance. Statistics are available for undo space 
consumption, transaction concurrency, the tuning of undo retention, and the length 
and SQL ID of long-running queries in the instance. 

Each row in the \'iew contains statistics collected in the instance for a ten-minute 
interval. The rows are in descending order bv theBEGIW_TIME column value. Each 
row belongs to the time interval marked by (BEGIN_TIME, END_TIME). Each column 
represents the data collected for the particular statistic in that time interval. The first 
row of the view contains statistics for the (partial) current time period. The view 
contains a total of 576 rows, spanning a 4 day cycle. 

The following example shows the results of a query on the VSUNDOSTAT view. 

SELECT TO_CHAR(BEGIH_TIME, 'MM/DD/YYYY HH24:HI:SS') BEGIH_TIME, 
TO_CHAR(EKD_TIME, ' MM/DD/YYYY HH24:MI;SS') EHD_TIME, 
DNDOTSN, UNDOBLKS, TSNCODNT, MflXCOHCDRRKKCY AS "MAXCOK" 
FROM vSUKDOSTAT WHERE rownum <= 144; 



BEGIN TIME 



END TIME 



UNDOBLKS TKNCOUKT 



10/23/2004 14:25:12 10/28/2004 14:32:17 

10/23/2004 14:15:12 10/28/2004 14:25:12 

10/28/2004 14:05:12 10/28/2004 14:15:12 

10/28/2004 13:55:12 10/28/2004 14:05:12 



74 12071108 

49 120706S8 

125 12070220 

99 120t6511 



10/27/2004 14:45:12 10/27/2004 14:55:12 
10/27/2004 14:35:12 10/27/2004 14:45:12 



15 
154 



11831676 
11831165 



144 TO\js selected. 



The preceding example shows how undo space is consumed in the svstem for the 
previous 24 hours from the time 14:35:12 on 10/27/2004. 
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Using Oracle-Managed Files 



In this chapter: 

What Are Oracle-Managed Files? 

Enabhng the Creation and Use of Oracle-Managed Files 

Creating Oracle-Managed Files 

Behavior of Oracle-Managed Files 

Scenarios for Using Oracle-Managed Files 



What Are Oracle-Managed Files? 



Using Oracle-managed files simplifies the administration of an Oracle Database, 
Oracle-managed files eliminate the need for you, the DBA, to directly manage the 
operating system files that make up an Oracle Database. With Oracle-managed files, 
you specifv file system directories in which the database automatically creates, names, 
and manages files at the database object level. For example, you need only specifv that 
you want to create a tablespace; you do not need to specifv the name and path of the 
tablespace's datafile with the DATAFILE clause. This feature works well with a logical 
volume manager (LVM), 

The database internally uses standard file system interfaces to create and delete files as 
needed for the following database structures: 

Table spaces 

Redo log files 

Control files 

Archived logs 

Block change tracking files 

Flashback logs 

RMAN backups 

Through initialization parameters, you specifv the file svstem director}" to be used for 
a particular t\'pe of file. The database then ensures that a unique file, an 
Oracle-managed file, is created and deleted when no longer needed. 

This feature does not affect the creation or naming of administrative files such as trace 
files, audit files, alert logs, and core files. 
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See Also: Oracle Database Storage Administrator's Guide for 
mformation about Automatic Storage Management (ASM), the 
Oracle Database integrated file system and volume manager that 
extends the power of Oracle-managed files. With Oracle- managed 
files, files are created and managed automatically for you, but with 
ASM, you get the additional benefits of features such as striping, 
software mirroring, and dynamic storage configuration, without 
the need to purchase a third-partv logical volume manager. 

Who Can Use Oracle-Managed Files? 

Oracle- managed files are most useful for the following tvpes of databases: 

■ Databases that are supported by the following: 

- A logical volume manager that supports striping/RAID and dynamically 
extensible logical volumes 

- A file system that provides large, extensible files 

■ Low end or test databases 

The Oracle-managed files feature is not intended to ease administration of systems 
that use raw disks. This feature provides better integration with operating system 
functionalitv for disk space allocation. Since there is no operating system support for 
allocation of raw disks (it is done manually), this feature cannot help. On the other 
hand, because Oracle-managed files require that you use the operating system file 
svstem (unlike raw disks), you lose control over how files are laid out on the disks and 
thus, you lose some I/O tuning ability 

What Is a Logical Volume Manager? 

A logical volume manager (LVM) is a softivare package available with most operating 
systems. Sometimes it is called a logical disk manager (LDM), It allows pieces of 
multiple physical disks to be combined into a single contiguous address space that 
appears as one disk to higher layers of software. An LVM can make the logical volume 
have better capacity, performance, reliabilit}', and availability characteristics than any 
of the underlying physical disks. It uses techniques such as mirroring, striping, 
concatenation, and RAID 5 to implement these characteristics. 

Some LVMs allow the characteristics of a logical volume to be changed after it is 
created, even while it is in use. The volume may be resized or mirrored, or it may be 
relocated to different physical disks. 

What Is a File System? 

A file system is a data structure built inside a contiguous disk address space. A file 
manager (FM) is a software package that manipulates file systems, but it is sometimes 
called the file system. All operating systems have file managers. The primary task of a 
file manager is to allocate and deallocate disk space into files within a file svstem, 

A file system allows the disk space to be allocated to a large number of files. Each file 
is made to appear as a contiguous address space to applications such as Oracle 
Database, The files may not actually be contiguous within the disk space of the file 
svstem. Files can be created, read, written, resized, and deleted. Each file has a name 
associated with it that is used to refer to the file, 

A file system is commonly built on top of a logical volume constructed by an LVM, 
Thus all the files in a particular file system have the same performance, reliability, and 
availability characteristics inherited from the underlying logical volume, A file system 
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is a single pool of storage that is shared hv all the files in the file system. If a file system 
is out of space, then none of the files in that file system can grow. Space available in 
one file svstem does not affect space in another file system. However some LVM/FM 
combinations allow space to be added or removed from a file svstem. 

An operating system can support multiple file svstems. Multiple file systems are 
constructed to give different storage characteristics to different files as well as to 
divide the available disk space into pools that do not affect each other. 

Benefits of Using Oracle-Managed Files 

Consider the following benefits of using Oracle-managed files: 

■ They make the administration of the database easier. 

There is no need to invent filenames and define specific storage requirements. A 
consistent set of rules is used to name all relevant files. The file system defines the 
characteristics of the storage and the pool where it is allocated. 

■ Thev reduce corruption caused by administrators specifving the wrong file. 

Each Oracle- managed file and filename is unique. Using the same file in two 
different databases is a common mistake that can cause verv large down times and 
loss of committed transactions. Using two different names that refer to the same 
file is another mistake that causes major corruptions. 

■ Thev reduce wasted disk space consumed by obsolete files, 

Oracle Database automatically removes old Oracle-managed files when they are 
no longer needed. Much disk space is wasted in large systems simply because no 
one is sure if a particular file is still required. This also simplifies the 
administrative task of removing files that are no longer required on disk and 
prevents the mistake of deleting the wrong file, 

■ They simplify creation of test and development databases. 

You can minimize the time spent making decisions regarding file structure and 
naming, and you have fewer file management tasks. You can focus better on 
meeting the actual requirements of your test or development database, 

■ Oracle- managed files make development of portable third-party tools easier, 

Oracle-managed files eliminate the need to put operating svstem specific file 
names in SQL scripts, 

Oracle-Managed Files and Existing Functionality 

Using Oracle-managed files does not eliminate any existing functionality. Existing 
databases are able to operate as they always have. New files can be created as 
managed files while old ones are administered in the old wav. Thus, a database can 
have a mixture of Oracle-managed and unmanaged files. 

Enabling the Creation and Use of Oracle-Managed Files 

The following initialization parameters allow the database server to use the 
Oracle-managed files feature: 
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Initialization Parameter 



Description 



DB CREATE FILE BEST 



DB CREATE ONLIHE LOG DEST n 



DB RECOVERY FILE DEST 



Defines the location of the default file system 
directory where the database creates datafiles or 

tempfiles when no file specification is given in the 
creation operation. Also used as the defauU file 
system directory for redo log and control files if 
D"B_CREATE_0NLIHE_L0G_DE3T_n is not specified. 

Defines (he location of the default file system 
directory for redo log files and control file creation 
when no file specification is given in the creation 
operation. You can use this initialization parameter 
multiple times, where n specifies a multiplexed copy 
of the redo log or control file. You can specify up to 
five multiplexed copies 

Defines the location of the flash recovery area, 
which is the default file system directory where the 
database creates RMAN backups when no format 
option is used, archived logs when no other local 
destination is configured, and flashback logs. Also 
used as the default file system directory for redo log 
and control files if 
DB_CREATE_ONLIHE_LOG_DEST_n is not specified. 



The file system, directory specified by either of these parameters must already exist; 
the database does not create it. The directory must also have permissions to allow the 
database to create the files in it. 

The default location is used whenever a location is not explicitly specified for the 
operation creating the file. The database creates the filename, and a file thus created is 
an Oracle-managed file. 

Both of these initialization parameters are dynamic, and can be set using the ALTER 

SYSTEM or ALTER SESSION statement. 

See Also: 

■ Oracle Database Reference for additional information about 
initialization parameters 

■ "How Oracle-Managed Files Are Named" on page 15-6 

Setting the DB_CREATE_FILE_DEST Initialization Parameter 

Include the DB_CREATE_FILE_DEST initialization parameter in your initialization 
parameter file to identify the default location for the database server to create: 

■ Datafiles 

■ Tempfiles 

■ Redo log files 

■ Control files 

■ Block change tracking files 

You specify the name of a file system director\' that becomes the default location for 
the creation of the operating system files for these entities. The following example sets 
/uOl/oradata as the default directory to use when creating Oracle-managed files: 

DB_CREATE_FILE_DEST = '/uOl/oradata ' 
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Setting the DB_RECOVERY_FILE_DEST Parameter 

Include the DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_giZE 

parameters in your initialization parameter file to identify the default location in 
which Oracle Database should create: 

Redo log files 

Control files 

RMAN backups (datafile copies, control file copies, backup pieces, control file 
auto backups) 

Archived logs 

Flashback logs 

You specify the name of file svstem director}' that becomes the default location for 
creation of the operating svstem files for these entities. For example: 

DB_RECOVERY_FILE_DEST = ' /uOl/oradata ' 
DB_RECOVERY_FILE_DEST_SIZE = 20G 

Setting the DB_CREATE_ONLINE_LOG_DEST_n Initialization Parameter 

Include the DB_CREATE_ONLINE_LOG_DEST_i] initialization parameter in your 
initialization parameter file to identify the default location for the database server to 
create: 

■ Redo log files 

■ Control files 

You specify the name of a file svstem director}' that becomes the default location for 
the creation of the operating system files for these entities. You can specify up to five 
multiplexed locations. 

For the creation of redo log files and control files only, this parameter overrides any default 
location specified in the DB_CREATE_FILE_DEST and DB_RBCOVERY_FILE_DEST 
initialization parameters. If you do not specify a DB_CREATE_FILE_DEST parameter, 
but you do specify the DB_CREATE_ONLINE_LOG_DEST_n parameter, then only redo 
log files and control files can be created as Oracle-managed files. 

It is recommended that you specify at least two parameters. For example: 

DB_CEEATE_0NLINE_L0G_DEST_1 = 7u02/oradata ' 
DE_CREATE_0NLINE_L0G_DEST_2 = 7u03/oradata ' 

This allows multiplexing, which provides greater fault-tolerance for the redo log and 
control file if one of the destinations fails. 



Creating Oracle-Managed Files 



If you ha\'e met any of the following conditions, then Oracle Database creates 
Oracle-managed files for you, as appropriate, when no file specification is given in the 
creation operation: 

■ You have included any of the DB_CREATE_FILE_DEST, 

DB_REDOVERY_FILE_DEST, or DB_CREATE_ONLINE_LOG_DEST_n initialization 

parameters in your initialization parameter file. 
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■ You have issued the ALTER SYSTEM statement to dynamically set anv of 

DB_EECOVEEY_FILE_DEST, DB_CREATE_FILE_DEST, or 

DB_CREATE_OWLIWE_LOG_DEST_n initialization parameters 

■ You have issued tlie ALTER SESSION statement to dynamically set any of the 

DB_CREATE_FILE_DEST, DB_RECOVERY_FILE_DEST, or 

DB_CREATE_OWLIWE_LOG_DEST_n initialization parameters. 

If a statement that creates an Oracle-managed file finds an error or does not complete 
due to some failure, then any Oracle-managed files created by the statement are 
automatically deleted as part of the recovery of the error or failure. However, because 
of the large number of potential errors that can occur with file systems and storage 
subsystems, there can be situations where vou must manually remove the files using 
operating system commands. 

The following topics are discussed in this section; 

How Oracle-Managed Files Are Named 

Creating Oracle-Managed Files at Database Creation 

Creating Datafiles for Tablespaces Using Oracle-Managed Files 

Creating Tempfiles for Temporan' Tablespaces Using Oracle-Managed Files 

Creating Control Files Using Oracle-Managed Files 

Creating Redo Log Files Using Oracle-Managed Files 

Creating Archived Logs Using Oracle-Managed Files 



How Oracle-Managed Files Are Named 



The filenames of Oracle-managed files comply with the Optimal Flexible Architecture 
(OFA) standard for file naming. The assigned names are intended to naeet the 
following requirements; 

■ Database files are easily distinguishable from all other files. 

■ Files of one database t;'pe are easily distinguishable from other database types. 

■ Files are clearly associated with important attributes specific to the file type. For 
example, a datafile name may include the tablespace name to allow for easy 
association of datafile to tablespace, or an archived log name may include the 
thread, sequence, and creation date. 

No two Oracle-managed fUes are given the same name. The name that is used for 
creation of an Oracle-managed file is constructed from three sources; 

■ The default creation location 

■ A file name template that is chosen based on the t\'pe of the file. The template also 
depends on the operating system platform and w^hether or not automatic storage 
management is used. 

■ A unique string created by the Oracle Database server or the operating system. 
This ensures that file creation does not damage an existing file and that the file 
cannot be mistaken for some other file. 

As a specific example, filenames for Oracle- managed files have the following format 
on a Solaris file system.: 

<deE t i na t i on_pr e f i JO / o l_mf J t_%"u_ . db f 
w^here; 
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■ <destina.tion._prefix> is 
<destin3.tion_loc3.tlon>/<db_unique_na.!ne>/<da ta.file> 

where: 

- <destin3.tion_loca.tion> is the location specified in 

DB_CREATE_FILE_DEST 

- <db_u.ni que_naine> is the globally unique name (DB_UNIQUE_NAME 
initialization parameter) of the target database. If there is no 

DB_UNI QUE_NAME parameter, then the DB_NAME initialization parameter 
value is used, 

■ %t is the tablespace name. 

■ %u is an eight-character string that guarantees uniqueness 
For example, assume the following parameter settings: 

DB_CEEATE_FILE_DE3T = /uOl/oradata 
DB_UMIQUE_HAME = PAYROLL 

Then an example datafile name would be: 

/u01/oradata/PAYEOLL/datafile/ol_mf_tbsl_2ixh90q_.dbf 

Names for other file types are similar. Names on other platforms are also similar, 
subject to the constraints of the naming rules of the platform. 

The examples on the following pages use Oracle-managed file names as they might 
appear with a Solaris file system as an OMF destination. 

Caution: Do not rename an Oracle-managed file. The database 
identifies an Oracle- managed file based on its name. If vou renam.e 
the file, the database is no longer able to recognize it as an 
Oracle-managed file and will not manage the file accordingly. 

Creating Oracle-Managed Files at Database Creation 

The behavior of the CREATE DATABASE statement for creating database structures 
when using Oracle- managed files is discussed in this section. 

See Also: Oracle Database SQL Language Reference for a description 

of the CREATE DATABASE statement 

Specifying Control Files at Database Creation 

At database creation, the control file is created in the files specified by the 
CONTROL_FILES initialization parameter If the COHTROL_FILES parameter is not set 
and at least one of the initialization parameters required for the creation of 
Oracle- managed files is set, then an Oracle-managed control file is created in the 
default control file destinations. In order of precedence, the default destination is 
defined as follows: 

■ One or more control files as specified in the DB_CREATE_OHLIHE_LOG_DEST_rj 
initialization parameter. The file in the first directory is the primary control file. 
When DB_CREATE_0NLINE_L0G_DEST_!3 is specified, the database does not 
create a control file in DB_CREATE_FILE_DEST or in DB_RECOVERY_FILE_DEST 
(the flash recovery area). 
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■ If no value is specified for DB_CREATE_ONLINE_LOG_DEST_n, but values are set 
forhoththeDB_CREATE_FILE_DEST and DB_RECOVERY_FILE_DEST, then the 
database creates one control file in each location. The location specified in 
DB_CREATE_FILE_DEST is the primary control file. 

■ If a value is specified only for DB_CREATE_FILE_DE3T, then the database creates 
one control file in that location. 

■ If a value is specified only for DB_RECOVERY_FILE_DEST. then the database 
creates one control file in that location. 

If the CONTROL_FILES parameter is not set and none of these initialization 
parameters are set. then the Oracle Database default behavior is operating svstem 
dependent. At least one copy of a control file is created in an operating system 
dependent default location. Any copies of control files created in this fashion are not 
Oracle-managed files, and you must add a COWTROL_FILES initialization parameter 
to anv initialization parameter file. 

If the database creates an Oracle-managed control file, and if there is a server 
parameter file, then the database creates a CONTROL_FILES initialization parameter 
entry in the ser\'er parameter file. If there is no server parameter file, then vou must 
manually include a CONTROL_FILES initialization parameter entry in the text 
initialization parameter file. 

See Also: Chapter 9, "Managing Control Files" 

Specifying Redo Log Files at Database Creation 

The LOGFILE clause is not required in the CREATE DATABASE statement, and 
omitting it provides a simple means of creating Oracle-managed redo log files. If the 
LOGFILE clause is omitted, then redo log files are created in the default redo log file 
destinations. In order of precedence, the default destination is defined as follows: 

■ If either the DB_CREATE_OWLIWE_LOG_DEST_n is set, then the database creates a 
log file member in each directory specified, up to the value of the 
MAXLOGMEMBERS initialization parameter. 

■ If the DB_CREATE_OWLIWE_LOG_DEST_ii parameter is not set, but both the 

DB_CREATE_FILE_DEST and DB_RECOVERY_FILE_DEST initialization 

parameters are set. then the database creates one Oracle- managed log file member 
in each of those locations. The log file in the DB_CREATE_FILE_DEST destination 
is the first member 

■ If only the DB_CREATE_FILE_DEST initialization parameter is specified, then the 
database creates a log file member in that location, 

■ If only the DB_RECOVERY_FILE_DEST initialization parameter is specified, then 
the database creates a log file member in that location. 

The default size of an Oracle-managed redo log file is 100 MB, 

Optionallv. vou can create Oracle-managed redo log files, and override default 
attributes, bv including the LOGFILE clause but omitting a filename. Redo log files are 
created the same wav, except for the following: If no filename is provided in the 
LOGFILE clause of CREATE DATABASE, and none of the initialization parameters 
required for creating Oracle-managed files are provided, then the CREATE DATABASE 
statement fails. 

See Also: Chapter 10, "Managing the Redo Log" 
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Specifying tlie SYSTEM and SYSAUX Tablespace Datafiles at Database Creation 

TheDATAFILE or SYSAUX DATAFILE clause is not required in the CREATE 
DATABASE statement, and omitting it provides a simple means of creating 
Oracle-managed datafiles for the SYSTEM and SYSAUX tablespaces. If the DATAFILE 
clause is omitted, then one of the following actions occurs: 

■ If DB_CREATE_FILE_DEST is set, then one Oracle- managed datafile for the 
SYSTEM tablespace and another for the SYSAUX tablespace are created in the 

DB_CREATE_FILE_DEST directory. 

■ If DB_CREATE_FILE_DEST is not set, then the database creates one SYSTEM, and 
one SYSAUX, tablespace datafile whose name and size are operating svstem 
dependent. Anv SYSTEM or SYSAUX tablespace datafile created in this manner is 
not an Oracle- managed file. 

The default size for an Oracle-managed datafile is 100 MB and the file is 
auto extensible. When autoextension is required, the database extends the datafile by 
its existing size or 100 MB, whichever is smaller You can also explicitly specifv the 
auto extensible unit using the NEXT parameter of the STORAGE clause when you 
specify the datafile (in a CREATE or ALTER TABLESPACE operation). 

Optionally, you can create an Oracle-managed datafile for the SYSTEM or SYSAUX 
tablespace and override default attributes. This is done bv including the DATAFILE 
clause, omitting a filename, but specifying overriding attributes. When a filename is 
not supplied and the DB_CREATE_FILE_DEST parameter is set, an Oracle-managed 
datafile for the SYSTEM or SYSAUX tablespace is created in the 
DB_CREATE_FILE_DEST directory with the specified attributes being overridden. 
However, if a filename is not supphed and the DB_CREATE_FILE_DEST parameter is 
not set, then the CREATE DATABASE statement fails. 

When overriding the default attributes of an Oracle-managed file, if a SIZE value is 
specified but no AUTOEXTEND clause is specified, then the datafile is not 
autoextensible , 

Specifying tlie Undo Tabiespace Datafiie at Database Creation 

The DATAFILE subclause of the UWDO TABLESPACE clause is optional and a filename 
is not required in the file specification. If a filename is not supplied and the 
DB_CREATE_FILE_DEST parameter is set, then an Oracle-managed datafile is created 
in the DB_CREATE_FILE_DEST directory. If DB_CREATE_FILE_DEST is not set, then 
the statement fails with a syntax error. 

The UNDO TABLESPACE clause itself is optional in the CREATE DATABASE statement. 
If it is not supplied, and automatic undo management mode is enabled, then a default 
undo tablespace named SYS_UNDOTBS is created and a 10 MB datafile that is 
autoextensible is allocated as follows: 

■ If DB_CREATE_FILE_DEST is set. then an Oracle-managed datafile is created in 
the indicated directory. 

■ If DB_CREATE_FILE_DEST is not set. then the datafile location is operating 
system specific. 

See Also: Chapter 14, "Managing Undo" 

Specifying tlie Default Temporary Tablespace Tempfile at Database Creation 

TheTEMPFILE subclause is optional for the DEFAULT TEMPORARY TABLESPACE 
clause and a filename is not required in the file specification. If a filename is not 
supplied and the DB_CREATE_FILE_DEST parameter set, then an Oracle-managed 
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tempfile is created in the DB_CREATE_FILE_DEST directory. If 

DB_CREATE_FILE_DEST is not set, tiien the CREATE DATABASE statement fails with 
a syntax error. 

The DEFAULT TEMPORARY TABLESPACE clause itself is optional. If it is not specified, 
then no default temporary tablespace is created. 

The default size for an Oracle-managed tempfile is 100 MB and the file is 
autoextensible with an unlimited maximum size, 

CREATE DATABASE Statement Using Oracle-Managed Files: Examples 

This section contains examples of the CREATE DATABASE statement when using the 
Oracle-managed files feature. 

CREATE DATABASE: Example 1 This example creates a database with the following 
Oracle-managed files: 

■ A SYSTEM tablespace da tafile in directory /uDl/oradata that is 100 MB and 
auto extensible up to an unlimited size. 

■ A SYSAUX tablespace datafile in directory /uOl/oradata that is 100 MB and 
auto extensible up to an unlimited size. The tablespace is locally managed with 
automatic segment-space management. 

■ Two online log groups with two members of 100 MB each, one each in 

/u02/oradata and /u0 3/oradata . 

■ If automatic undo management mode is enabled, then an undo tablespace datafile 
in directory /uDl/oradata that is 10 MB and autoextensible up to an unlimited 
size. An undo tablespace named SYS_UNDOTBS is created. 

■ If no CONTROL_FILES initialization parameter is specified, then two control files, 
one each in /u02/oradata and /u03/oradata. The control file in 

/u0 2/oradata is the primary control file. 

The following parameter settings relating to Oracle- managed files, are included in the 
initialization parameter file: 

DB_CEEATE_FILE_DEST = 7u01/oradata ' 
DB_CEEATE_0NLINE_L0G_DEST_1 = 7u02/oradata' 
DB_CHEATE_0NLINE_L0G_DEST_2 = 7u03/oradata' 

The following statement is issued at the SQL prompt: 

SQL> CREATE DATABASE sample; 

CREATE DATABASE: Example 2 This example creates a database with the following 
Oracle-managed files: 

■ A 100 MB SYSTEM tablespace datafile in directory /uDl/oradata that is 
autoextensible up to an unlimited size. 

■ A SYSAUX tablespace datafile in directory /uOl/oradata that is 100 MB and 
autoextensible up to an unlimited size. The tablespace is locally managed with 
automatic segment-space management. 

■ Two redo log files of 100 MB each in directory /uOl/oradata. Thev are not 
multiplexed. 

■ An undo tablespace datafile in directory /uOl/oradata that is 10 MB and 
autoextensible up to an unlimited size. An undo tablespace named SYS_UNDOTBS 
is created. 
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■ A control file in /uOl/oradata. 
In this example, it is assumed that: 

■ No DB_CREATE_OHLIHE_LOG_DEST_!j initialization parameters are specified in 
the initialization parameter file. 

■ No CONTROL_FILES initialization parameter was specified in the initialization 
parameter file. 

■ Automatic undo management mode is enabled. 
The following statements are issued at the SQL prompt: 

SQL> ALTER SYSTEM SET DE_CREATE_FII£_DE3T = 7u01/oradata ' ; 
S2L> CREATE DATABASE Eample2 ; 

This database configuration is not recommended for a production database. The 
example illustrates how a very low-end database or simple test database can easily be 
created. To better protect this database from failures, at least one more control file 
should be created and the redo log should be multiplexed, 

CREATE DATABASE: Example 3 In this example, the file size for the 
Oracle-managed files for the default temporarv tablespace and undo tablespace are 
specified, A database with the following Oracle-managed files is created: 

■ A 400 MB SYSTEM tablespace da tafile in directory /uOl/oradata, Because SIZE 
is specified, the file in not autoextensible, 

■ A 200 MB SYSAUX tablespace datafile in directory /uOl/oradata. Because SIZE 
is specified, the file in not autoextensible. The tablespace is locally managed w^ith 
automatic segment-space management, 

■ Tw^o redo log groups with two members of 100 MB each, one each in directories 

/u02/oradata and /u03/oradata . 

■ For the default temporary tablespace df lt_ts, a 10 MB tempfile in directory 
/uDl/oradata, Because SIZE is specified, the file in not autoextensible, 

■ For the undo tablespace undo_ts, a 10 MB datafile in directory /uOl/oradata, 
Because SIZE is specified, the file in not autoextensible, 

■ If no CONTROL_FILES initialization parameter was specified, then two control 
files, one each in directories /u02/oradata and /u03/oradata. The control file 
in /u02/oradata is the primary control file. 

The following parameter settings are included in the initialization parameter file: 

DE_CREATE_FILE_DE3T = 7u01/oradata ' 
DB_CREATE_0NLINE_L0G_DEST_1 = 7u02/oradata' 
DB_CREATE_0NLINE_L0G_DEST_2 = 7u03/oradata ' 

The following statement is issued at the SQL prompt: 

SQL> CREATE DATABASE sampleS DATAFILE SIZE 400M 

2> SYSAUX DATAFILE SIZE 200M 

3> DEFAULT TEMPORARY TABLESPACE dflt_tE TEMPFILE SIZE lOM 

4> UNDO TABLESPACE undo_ts DATAFILE SIZE lOH; 



Creating Datafiles for Tablespaces Using Oracle-Managed Files 



The following statements that can create datafiles are relevant to the discussion in this 
section: 
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■ CREATE TABLESPACE 

■ CREATE UNDO TABLESPACE 

■ ALTER TABLESPACE ... ADD DATAFILE 

When creating a tablespace, either a regular tablespace or an undo tahlespace, the 
DATAFILE clause is optional. When vou include the DATAFILE clause the filename is 
optional. If the DATAFILE clause or filename is not provided, then the following rules 
apply: 

■ If the DB_CREATE_FILE_DEST initialization parameter is specified, then an 
Oracle- managed datafile is created in the location specified hv the parameter. 

■ If theDB_CREATE_FILE_DEST initialization parameter is not specified, then the 
statement creating the datafile fails. 

When you add a datafile to a tablespace with the ALTER TABLESPACE. . .ADD 
DATAFILE statement the filename is optional. If the filename is not specified, then the 
same rules apply as discussed in the previous paragraph. 

Bv default, an Oracle-managed datafile for a regular tablespace is 100 MB and is 
auto extensible with an unlimited maximum size. However, if in vour DATAFILE 
clause you override these defaults by specifying a SIZE value (and no AUTOEXTEWD 
clause), then the datafile is iiol autoextensible. 

See Also: 

. "Specifying the SYSTEM and SYSAUX Tablespace Datafiles at 
Database Creation" on page 15-9 

■ "Specifying the Undo Tablespace Datafile at Database Creation" 
on page 15-9 

■ Chapter 12, "Managing Tablespaces" 

CREATE TABLESPACE: Examples 

The following are some examples of creating tablespaces with Oracle-managed files. 

See Also: Oracle Daiabase SQL Language Reference for a description 

of the CREATE TABLESPACE statement 

CREATE TABLESPACE: Example 1 The following example sets the defauh location 
for datafile creations to /uOl/oradata and then creates a tablespace tbE_l with a 
datafile in that location. The datafile is 100 MB and is autoextensible with an unlimited 
maximum size. 

SQL> ALTER SYSTEM SET DB_CREftTE_FILE_DEST = 7u01/oradata ' ; 
SQL> CREATE TABLESPACE tbs.l; 

CREATE TABLESPACE: Example 2 This example creates a tablespace named tbs_2 
with a datafile in the director)' /uOl/oradata. The datafile initial size is 400 MB, and 
because the SIZE clause is specified, the datafile is not autoextensible. 

The following parameter setting is included in the initialization parameter file: 

DB_CREATE_FILE_DEST = '/uOl/oradata ' 

The following statement is issued at the SQL prompt 

SeL> CREATE TABLESPACE tbE_2 DATAFILE SIZE 400M; 
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CREATE TABLESPACE: Examples This example creates a tablespace named tbs_3 
with an autoextensible datafile in the directory /uOl/oradata with a maximum size 
of 800 MB and an initial size of 100 MB: 

The following parameter setting is included in the initialization parameter file; 

DB_CEEATE_FILE_DEST = 7u01/oradata ' 

The following statement is issued at the SQL prompt: 

S2L> CREATE TABI£3PACE tbE_3 DATAFILE AUTOEXTEND OH MAZSIZE 800Mr 

CREATE TABLESPACE: Example 4 The following example sets the default location 
for datafile creations to /uOl/oradata and then creates a tablespace named tbs_4 in 
that directory with two datafiles. Both datafiles have an initial size of 200 MB, and 
because a SIZE value is specified, they are not autoextensible 

S2L> ALTER SYSTEM SET DB_CREATE_FILE_DE3T = '/uOl/oradata ' ; 
SQL> CREATE TABLESPACE tbE_4 DATAFILE SIZE 200M SIZE 200M; 

CREATE UNDO TABLESPACE: Example 

The following example creates an undo tablespace named undotbs_l with a datafile 
in the directory /uOl/oradata. The datafile for the undo tablespace is 100 MB and is 
autoextensible with an unlimited maximum size. 

The following parameter setting is included in the initialization parameter file: 

DB_CEEATE_FILE_DEST = 7u01/oradata ' 

The following statement is issued at the SQL prompt: 

SQL> CREATE UNDO TABLESPACE undotbs_l; 

See Also: Oracle Database SQL Language Reference for a description 

of the CREATE UNDO TABLESPACE statement 

ALTER TABLESPACE: Example 

This example adds an Oracle-managed autoextensible datafile to the tbs_l 

tablespace. The datafile has an initial size of 100 MB and a maximum size of 800 MB. 

The following parameter setting is included in the initialization parameter file: 

DB_CEEATE_FILE_DEST = 7u01/oradata ' 

The following statement is entered at the SQL prompt: 

SQL> ALTER TABLESPACE tbs_l ADD DATAFILE AUTOEXTEND OH MAXSIZE SOOM; 

See Also: Oracle Database SQL Language Reference for a description 

oftheALTER TABLESPACE statement 

Creating Tempfiles for Temporary Tablespaces Using Oracle-Managed Files 

The following statements that create tempfiles are relevant to the discussion in this 
section: 

■ CREATE TEMPORARY TABLESPACE 

■ ALTER TABLESPACE ... ADD TEMPFILE 
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When creating a temporary tablespace the TEMP FILE clause is optional. If vou include 
the TEMPFILE clause, then the filename is optional. If the TEMPFILE clause or 
filename is not provided, then the following rules apply: 

■ If the DB_CREATE_FILE_DEST initialization parameter is specified, then an 
Oracle-managed tempfile is created in the location specified by the parameter. 

■ If theDB_CREATE_FILE_DEST initialization parameter is not specified, then the 
statement creating the tempfile fails. 

When you add a tempfile to a tablespace with the ALTER TABLESPACE . . . ADD 
TEMPFILE statement the filename is optional. If the filename is not specified, then the 
same rules apply as discussed in the previous paragraph. 

When overriding the default attributes of an Oracle-managed file, if a SIZE value is 
specified but no AUTOEXTEWD clause is specified, then the datafile is iilj; 
autoex tensib le . 

See Also: "Specifving the Default Temporary Tablespace 
Tempfile at Database Creation" on page 15-9 

CREATE TEMPORARY TABLESPACE: Example 

The following example sets the default location for datafile creations to 
/uOl/oradata and then creates a tablespace named temptbs_l with a tempfile in 
that location. The tempfile is 100 MB and is autoex tens ibie with an unlimited 
maximum size. 

SeL> ALTER SYSTEM SET DB_CREATE_FILE_DEST = 7u01/oradata ' ; 
S2L> CREATE TEMPORARY TABLESPACE teraptbs_l; 

See Also: Oracle Database SQL Language Reference for a description 

of the CREATE TABLESPACE statement 

ALTER TABLESPACE... ADD TEMPFILE: Example 

The following example sets the default location for datafile creations to 
/u03/oradata and then adds a tempfile in the default location to a tablespace named 
teniptbs_l. The tempfile initial size is 100 MB. It is autoex tens ible with an unlimited 
maximum size. 

SQL> ALTER SYSTEM SET DB_CREATE_FILE_DEST = 7ii03/Dradata ' ; 
SQL> ALTER TABLESPACE TBS_1 ADD TEMPFILE; 

See Also: Oracle Database SQL Language Reference for a description 

oftheALTER TABLESPACE statement 

Creating Control Files Using Oracle- (Via naged Files 

When you issue the CREATE CONTROLFILE statement, a control file is created (or 
reused, if REUSE is specified) in the files specified by the CONTROL_FILES 
initialization parameter. If the CONTROL_FILES parameter is not set, then the control 
file is created in the default control file destinations. The default destination is 
determined according to the precedence documented in "Specifying Control Files at 
Database Creation" on page 15-7. 

If Oracle Database creates an Oracle-managed control file, and there is a server 
parameter file, then the database creates a CONTROL_FILES initialization parameter 
for the server parameter file. If there is no server parameter file, then you must create a 
CONTROL_FILES initialization parameter manually and include it in the initialization 
parameter file. 
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If the datafiles in the database are Oracle-managed files, then the database- genera ted 
filenames for the files must be supplied in the DATAFILE clause of the statement. 

If the redo log files are Oracle- managed files, then the NORESETLOGS or RESETLOGS 
keyword determines what can be supplied in the LOGFILE clause: 

■ If the NORESETLOGS keyword is used, then the database-generated filenames for 
the Oracle- managed redo log files must be supplied in the LOGFILE clause. 

■ If the RESETLOGS keyword is used, then the redo log file names can be supplied 
as with the CREATE DATABASE statement. See "Specifying Redo Log Files at 
Database Creation" on page 15-8. 

The sections that follow contain examples of using the CREATE CGHTROLFILE 
statement with Oracle-managed files. 

See Also: 

■ Oracle Database SQL Language Reference for a description of the 

CREATE CONTROLFILE statement 

■ "Specifying Control Files at Database Creation" on page 15-7 

CREATE CONTROLFILE Using NORESETLOGS Keyword: Example 

The following CREATE CONTROLFILE statement is generated by an ALTER 
DATABASE BACKUP CONTROLFILE TO TRACE statement for a database with 
Oracle-managed datafiles and redo log files: 

CREATE COHTROLFILE 
DATABASE sample 
LOGFILE 

GROUP 1 ( 7o01/aradata/SMPLE/onlinelog/ol_mf_l_o220rtt9_.log' , 
' /u02/oradata/SMPLE/onlinelog/ol_mf_l_v2o0b2i3_.log' ) 
SIZE 10 OM, 
GROUP 2 (7u01/oradata/SAMPLE/onlinelog/ol_mf_2_p22056iw_.log' , 
7u02/oradata/SMPLE/onlinelog/ol_mf_2_p02rcyg3_.lag' } 
SIZE lOOM 
nORESETLOGS 

DATAFILE ' /uO 1/ or adata/ SAMPLE/ data f lie/ ol_mf_system_xu34ybm2_.dbf ' 
SIZE lOOM, 

' /uO 1/ or adata /SAMPLE/ data f lie/ ol_mf_sysaux_aawbmz 5 l_.dbf ' 
SIZE lOOM, 

7u01/oradata/SflHPLE/datafile/ol_mf_syE_midotbs_apqbmz51_.dbf ' 
SIZE 10 OH 
MAXLOGFILES 5 
MAXLOGHISTORY 100 
MAXDATAFILES 10 
MAXIHSTMCES 2 
ARCHIVELOG ; 

CREATE CONTROLFILE Using RESETLOGS Keyword: Exampie 

The following is an example of a CREATE CONTROLFILE statement with the 
RESETLOGS option. Some combination of DB_CREATE_FILE_DEST, 

DB_RECOVERY_FILE_DEST, and DB_CREATE_ONLINE_LOG_DEST_rj or must be set. 

CREATE COHTROLFILE 

DATAEASE sample 

RESETLOGS 

DATAFILE ' /uO 1/ or adata /SAMPLE/ data f lie/ ol_mf_3ystem_aawbmz 5 l_.dbf ' , 
' /uO 1/ or adata /SAMPLE/ data f lie/ ol_mf_sysaux_a:q'bmz 5 l_.dbf ' , 
7ii01/oradata/SAMPLE/datafile/ol_mf_sys_uiidotbs_azzbmz51_.dbf ' 
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SIZE 10 DM 
MAXLOGFILES 5 
MAXLOGHISTORY 100 
MAXDATaFILES 10 
MfiXIMSTMCES 2 
ARCHIVELOG ; 

Later, you must issue the ALTER DATABASE OPEN RESETLOGS statement to 
re-create the redo log files. This is discussed in "Using the ALTER DATABASE OPEN 
RESETLOGS Statement" on page 15-17. If the previous log files are Oracle-managed 
files, then thev are not deleted. 

Creating Redo Log Files Using Oracle- l\/lanaged Files 

Redo log files are created at database creation tune. They can also be created when you 
issue either of the following statements: 

■ ALTER DATABASE ADD LOGFILE 

■ ALTER DATABASE OPEN RESETLOGS 

See Also: Oracle Dalahase SQL Language Reforencc for a description 

of the ALTER DATABASE statement 

Using the ALTER DATABASE ADD LOGFILE Statement 

TheALTER DATABASE ADD LOGFILE statement lets vou later add a new group to 
your current redo log. The filename in the ADD LOGFILE clause is optional if vou are 
using Oracle-managed files. If a filename is not provided, then a redo log file is created 
in the default log file destination. The default destination is determined according to 
the precedence documented in "Specif;' ing Redo Log Files at Database Creation" on 
page 15-8. 

If a filename is not provided and you have not provided one of the initialization 
parameters required for creating Oracle- managed fUes, then the statement returns an 
error. 

The default size for an Oracle- man aged log fUe is 100 MB. 

You continue to add and drop redo log file members by specifying complete 
filenames. 

See Also: 

■ "Specifying Redo Log Files at Database Creation" on page 15-8 

■ "Creating Control Files Using Grade-Managed Files" on 
page 15-14 

Adding New Redo Log Files: Example The following example creates a log group 
with a member in /uOl/oradata and another member in /u02/oradata. The size 
of each log file is 100 MB. 

The following parameter settings are included in the initialization parameter fUe: 

DB_CHEATE_ONLINE_LOG_DEST_1 = 7u01/oradata' 
DB_CREATE_0HLINE_LOG_DEST_2 = 7u02/oradata' 

The following statement is issued at the SQL prompt: 

S2L> ALTER DATABASE ADD LOGFILE; 
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Using the ALTER DATABASE OPEN RESETLOGS Statement 

If voLL previoiislv created a control file specifying RESETLOGS and eitlier did not 
specify filenames or specified nonexistent filenames, then the database creates redo log 
filesfor you when you issue the ALTER DATABASE OPEN RESETLOGS statement. 
The rules for determining the directories in which to store redo log tiles, when none 
are specified in the control file, are the same as those discussed in "Specifying Redo 
Log Files at Database Creation" on page 15-8. 

Creating Archived Logs Using Oracle-Managed Files 

Archived logs are created in theDB_RECOVERY_FILE_DEST location when; 

■ The ARC or LGWR background process archives an online redo log or 

■ An ALTER SYSTEM ARHIVE LOG CURRENT statement is issued. 

For example, assume that the following parameter settings are included in the 
initialization parameter file: 

EB_RECOVERY_FILE_DEST_SIZE = 20G 

DB_RECOVERY_FILE_DEST = ' /uOl/oradata ' 

LOG ARCHIVE BEST 1 = ' LOCATION=USE DB RECOVERY FILE DEST ' 



Behavior of Oracle-Managed Files 



The filenames of Oracle-managed files are accepted in SQL statements wherever a 
filename is used to identify an existing file. These filenames, like other filenames, are 
stored in the control file and, if using Recovery Manager (RMAN) for backup and 
recovery, in the RMAN catalog. Thev are visible in all of the usual fixed and dynamic 
performance views that are available for monitoring datafiles and tempfiles (for 

example, V$DATAFILE or DBA_DATA_FILES}, 

The following are some examples of statements using database- genera ted filenames: 

S2L> ALTER DATABASE 

2> RENAME FILE ' /uOl/oradata/mydb/dataf ile/ol_mf_tbs01_ziw3bopb_.dbf ' 
3> TO '/uOl/oradata/mydb/tiEOlOl.dbf' ; 

SQL> ALTER DATABASE 

2> DROP LOGFILE 7u01/oradata/mydh/onlinelog/ol_mf_l_wo94n2xi_.lag' ; 

SQL> ALTER TABLE en^) 
1> ALLOCATE EXTENT 
3> (DATAFILE 7ii01/oradata/mydb/dataEile/ol_mf_tbsl_2ixfh90q_.d]:)f ' ] ; 

You can backup and restore Oracle-managed datafiles, tempfUes, and control files as 
you would corresponding non Oracle-managed files. Using data base- genera ted 
filenames does not impact the use of logical backup files such as export files. This is 
particularly important for tablespace point-in-time recovery (TSPITR) and 
transportable tablespace export files. 

There are some cases where Oracle-managed files behave differently. These are 
discussed in the sections that follow. 



Dropping Datafiles and Tempfiles 



Unlike files that are not managed by the database, when an Oracle-managed datafile 
or tempfile is dropped, the filename is removed from the control file and the file is 
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automatically deleted from the file system.. The statements that delete Oracle-managed 
files when they are dropped are: 

■ DROP TABLESPACE 

■ ALTER DATABASE TEMPFILE ... DROP 

You can also use these statements, which always delete files, Oracle-managed or not: 

■ ALTER TABLESPACE ... DROP DATAFILE 

■ ALTER TABLESPACE ... DROP TEMPFILE 



Dropping Redo Log Files 



When an Oracle- managed redo log file is dropped its Oracle- managed files are 
deleted. You specify the group or members to be dropped. The following statements 
drop and delete redo log files: 

■ ALTER DATABASE DROP LOGFILE 

■ ALTER DATABASE DROP LOGFILE MEMBER 

Renaming Files 

The following statements are used to rename files: 

■ ALTER DATABASE RENAME FILE 

■ ALTER TABLESPACE ... RENAME DATAFILE 

These statements do not actually rename the files on the operating system, but rather, 
the names in the control file are changed. If the old file is an Oracle-managed file and it 
exists, then it is deleted. You must specify each filename using the conyentions for 
filenames on your operating system when you issue this statement. 



Managing Standby Databases 



The dataf iles, control files, and redo log files in a standby database can be managed by 
the database. This is independent of whether Oracle-managed files are used on the 
primary database. 

When recovery of a standby database encounters redo for the creation of a datafile, if 
the datafile is an Oracle-managed file, then the recovery process creates an empty file 
in the local default file system location. This allows the redo for the new file to be 
applied immediately without any human intervention. 

When recovery of a standby database encounters redo for the deletion of a tablespace, 
it deletes any Oracle- managed datafiles in the local file system. Note that this is 
independent of the INCLUDING DATAFILES option issued at the primary database. 

Scenarios for Using Oracle-Managed Files 

This section further demonstrates the use of Oracle-managed files by presenting 
scenarios of their use. 

Scenario 1: Create and Manage a Database with Multiplexed Redo Logs 

In this scenario, a DBA creates a database where the datafiles and redo log files are 
created in separate directories. The redo log files and control files are multiplexed. The 
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database uses an undo tablespace, and has a default temporary tablespace. The 
following are tasks involved with creating and maintaining this database. 

1. Setting the initialization parameters 

The DBA includes three generic file creation defaults in the initialization 
parameter file before creating the database. Automatic undo management mode is 
also specified. 

DB_CEEATE_FII.E_DEST = '/"uOl/oradata ' 
DB_CREATE_0NLINE_L0G_DEST_1 = 7u02/oradata' 
DB_CREATE_0NLINE_L0G_DEST_2 = 7u03/oradata' 
mDO_MMAGEMENT = AUTO 

TheDB_CREATE_FILE_DEST parameter sets the default file system directory for 
the datafiles and tempfiles. 

TheDB_CREATE_ONLINE_LOG_DEST_l and DB_CREATE_0NLINE_L0G_DEST_2 

parameters set the default file system directories for redo log file and control file 
creation. Each redo log file and control file is multiplexed across the two 
directories. 

2. Creating a database 

Once the initialization parameters are set, the database can be created by using 
this statement: 

SQL> CREATE DATABASE sample 

2> DEFAULT TEMPORARY TABI£3PACE dElttMiip; 

Because a DATAFILE clause is not present and the DB_CREATE_FILE_DEST 
initialization parameter is set, the SYSTEM tablespace datafile is created in the 
default file system (/uOl/oradata in this scenario). The filename is uniquely 
generated by the database. The file is autoextensible with an initial size of 100 MB 
and an unlimited maximum size. The file is an Oracle- managed file. A similar 
datafile is created for the SYSAUX tablespace. 

Because a LOGFILE clause is not present, two redo log groups are created. Each 
log group has two members, with one member in the 

DB_CREATE_0NLINE_L0G_DEST_1 location and the other member in the 
DB_CREATE_0NLINE_L0G_DEST_2 location. The fUenames are uniquely 
generated bv the database. The log files are created with a size of 100 MB. The log 
file members are Oracle- managed files. 

Similarly, because the CONTROL_FILES initialization parameter is not present, 
and two DB_CREATE_ONLINE_LOG_DEST_n initialization parameters are 
specified, two control files are created. The control file located in the 
DB_CREATE_0NLINE_L0G_DEST_1 location is the primary control file; the 
control file located in the DB_CREATE_0NLINE_L0G_DEST_2 location is a 
multiplexed copv. The filenames are uniquely generated by the database. They are 
Oracle- managed files. Assuming there is a server parameter file, a 
CONTR0L_FILES initialization parameter is generated. 

Automatic undo management mode is specified, but because an undo tablespace 
is not specified and the DB_CREATE_FILE_DEST initialization parameter is set, a 
default undo tablespace named SYS_UNDOTBS is created in the directory 
specified by DB_CREATE_FILE_DEST. The datafile is a 10 MB datafile that is 
autoextensible. It is an Oracle-managed file. 

Lastly, a default tempo rarv tablespace named df 1 ttmp is specified. Because 
DB_CREATE_FILE_DEST is included in the parameter file, the tempfile for 
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df Ittmp is created in the directory specified bv that parameter. The tempfile is 
100 MB and is autoextensible with an uniimited maximum size. It is an 
Oracle-managed file. 

The resultant fUe tree, with generated filenames, is as follows; 

/■uOl 

/oradata 

/SMPLE 

/datafile 

/ol_mf_system_cinr7t30p_.dbf 
/ol_mf_syEa"ux_cinr7t88p_.dbf 
/ol_mf_syE_"undotbs_2ixfh90q_.dbf 
/ol_mf_dflttziip_157se6ff_.tir[p 
/■u02 

/oradata 

/SMPLE 

/onlinelog 

/ol_mf_l_0ornii31z_. log 
/ol_mf_2_2xyzl6am_. log 
/control file 

/ol_mf_cinr7t30p_.ctl 
/■u03 

/oradata 

/SMPLE 

/onlinelog 

/ol_mf_l_ixE"vin8w9_. log 
/ol_mf_2_q89l:inp2 8_.log 
/controlf ile 

/ol_mf_xlEr8t36_.ctl 

The internally generated filenames can be seen when selecting from the usual 
views. For example: 

SQL> SELECT HME FROM V$DATAFILE; 
HME 



/■uOl /oradata /SMPLE/ data f ile/ ol_mf_SYstera_cmr7t30p_.dbf 
/uO 1 / oradata / SMPLE/ data f ile/ ol_mf _sysaux_cmr7t8 8p_ . dbf 
/u01/oradata/SMPLE/datafile/ol_iiif_sys_undotbs_2ixfh90q_.dbf 

3 rows selected 

3. Managing control files 

The control file w^as created when generating the database, and a 
CONTROL_FILES initialization parameter was added to the parameter file. If 
needed, then the DBA can re-create the control file or build a new one for the 
database using the CREATE CONTROLFILE statement. 

The correct Oracle- managed filenames must be used in the DATAFILE and 

LOGFILE clauses, TheALTER DATABASE BACKUP CONTROLFILE TO TRACE 

statement generates a script with the correct filenames. Alternatively, the 
filenames can be found by selecting from the VSDATAFILE, VS TEMPFILE, and 
VSLOGFILE views. The following example re-creates the control file for the 
sample database: 

CREATE CONTROLFILE REUSE 
DATABASE sample 
LOGFILE 
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GROUP l(7u02/oradata/SMPI£/oiilinelog/ol_mf_l_0ornii31z_.log' , 

' /u03/oradata/SMPI£/onliiielog/ol_mf_l_ixfvm8w9_.log' } , 
GROUP 2 ( ' /u02/oradata/SMPI£/onlinelog/ol_mf_2 _2xyzl6ain_.log' , 
7u03/oradata/SMPI£/onlinelog/ol_mf_2 _q89tmp28_.log' } 
MORESETLOGS 

DATAFILE ' / uOl/ or adata/ SAMPLE/ data file/ol_mf_3ystem_ciiir 7 t30p_.<ibf ' , 
' /u01/oradata/SfflPLE/datafile/ol_iiif_sysaijx_crar7t88p_.<ibf ' , 
7-u01/oradata/SflMPLE/datafile/ol_mf_sys_undotbs_2ixfh90q_.dbf' . 
' /-uOl/oradata/SAMPLE/dataf ile/ol_mf_df ltl:iiip_1573e6f f_. trap ' 
MAXLOGFILES 5 
MAXLOGHISTORY 100 
MAXDATftFILES 10 
MAXIHSTMCES 2 
ARCHIVELOG ; 

The control file created by this statement is located as specified by the 
CONTROL_FILES initialization parameter that was generated when the database 
was created. The REUSE clause causes any existing files to be overwritten. 

4. Managing the redo log 

To create a new group of redo log files, the DBA can use the ALTER DATABASE 
ADD LOGFILE statement. The following statement adds a log file with a member 
in the DB_CREATE_0WL1WE_L0G_DEST_1 location and a member in the 
DB_CREATE_0NLINE_L0G_DEST_2 location. These files are Oracle-managed 
files, 

SQL> ALTER DATABASE ADD LOGFILE; 

Log file members continue to be added and dropped by specifying complete 
filenames. 

The GROUP clause can be used to drop a log group. In the following example the 
operating system file associated with each Oracle- managed log file member is 
automatically deleted, 

SQL> ALTER DATABASE DROP LOGFILE GROUP 3; 

5. Managing table spaces 

The default storage for all datafiles for future tablespace creations in the sample 
database is the location specified by the DB_CREATE_FILE_DEST initialization 
parameter (/uOl/ or adata in this scenario). Any datafiles for which no filename 
is specified, are created in the file svstem specified by the initialization parameter 

DB_CREATE_FILE_DEST, For example: 

SQL> CREATE TABLESPACE tbs.l; 

The preceding statement creates a tablespace whose storage is in /uOl/ or adata, 
A datafile is created with an initial of 100 MB and it is autoextensible with an 
unlimited maximum size. The datafile is an Oracle-managed file. 

When the tablespace is dropped, the Oracle-managed files for the tablespace are 
automatically removed. The following statement drops the tablespace and all the 
Oracle- managed files used for its storage: 

SQL> DROP TABLESPACE tbs_lr 

Once the first datafile is full, the database does not automatically create a new 
datafile. More space can be added to the tablespace by adding another 
Oracle-managed datafile. The following statement adds another datafile in the 
location specified by DB_CREATE_FILE_DEST: 
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SQL> ALTER TftBLESPACE tbs_l ADD DATAFILE; 

The default file system can be changed bv changing the initialization parameter. 
This does not change any existing datafiles. It only affects future creations. This 
can be done dynamically using the following statement: 

SQL> ALTER SYSTEM SET DB_CREATE_FILE_DE3T= ' /u04/oradata ' ; 

6. Archiving redo information 

Archiving of redo log files is no different for Oracle-managed files, than it is for 
unmanaged files, A file system location for the archived log files can be specified 
using the LOG_ARCHIVE_DEST_n initialization parameters. The filenames are 
formed based on the L G_ARCH I VE_ FORMAT parameter or its default. The 
archived logs are not Oracle-managed files 

7. Backup, restore, and recover 

Since an Oracle-managed file is compatible with standard operating system files, 
you can use operating system utilities to backup or restore Oracle-managed files. 
All existing methods for backing up, restoring, and recovering the database work 
for Oracle-managed files. 

Scenario 2: Create and Manage a Database with Database and Flash Recovery Areas 

In this scenario, a DBA creates a database where the control files and redo log files are 
multiplexed. Archived logs and RMAN backups are created in the flash recovery area. 
The following tasks are involved in creating and maintaining this database: 

1. Setting the initialization parameters 

The DBA includes the following generic file creation defaults: 

DB_CREATE_FILE_DE3T = 7u01/oradata ' 

DB_RECOVERY_FILE_DEST_SIZE = lOG 

DB_RECOVERY_FILE_DEST = ' /u02/oradata ' 

L0G_ARCHIVE_DEST_1 = ' LOCATIOK = USE_DB_RECOVERY_FILE_DEST ' 

TheDB_CREATE_FILE_DEST parameter sets the default file system directory for 
datafiles, tempfiles, control files, and redo logs. 

The DB_RECOVERY_FILE_DEST parameter sets the default file system director}' 
for control files, redo logs, and RMAN backups. 

The L0G_AECHIVE_DEST_1 configuration 
'L0CATI0N=USE_DB_REC0VERY_FILE_DEST' redirects archived logs to the 

DB_RECOVERY_FILE_DEST location, 

TheDB_CREATE_FILE_DEST and DB_RECOVERY_FILE_DEST parameters set the 
default directorv for log file and control file creation. Each redo log and control file 
is multiplexed across the two directories, 

2. Creating a database 

3. Managing control files 

4. Managing the redo log 

5. Managing tablespaces 

Tasks 2, 3, 4, and 5 are the same as in Scenario 1, except that the control files and 
redo logs are multiplexed across the DB_CREATE_FILE_DEST and 

DB RECOVERY FILE BEST locations. 
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6. Archiving redo log information 

Archiving onhne logs is no different for Oracle-managed files than it is for 
unmanaged files. The archived logs are created in DB_RECOVERY_FILE_DEST 
and are Oracle-managed files. 

7. Backup, restore, and recover 

An Oracle- managed file is compatible with standard operating system files, so you 
can use operating svstem utilities to backup or restore Oracle- managed files. All 
existing methods for backing up, restoring, and recovering the database work for 
Oracle-managed files. When no format option is specified, all disk backups by 
RMAN are created in the DB_RECOVERY_FILE_DEST location. The backups are 
Oracle-managed files. 

Scenario 3: Adding Oracle-il/lanaged Fiiesto an Existing Database 

Assume in this case that an existing database does not have any Oracle-managed files, 
but the DBA would like to create new tablespaces with Oracle- managed files and 
locate them in directory /u03/oradata. 

1. Setting the initialization parameters 

To allow automatic d a tafile creation, set the DB_CREATE_FILE_DEST 
initialization parameter to the file system directory in which to create the datafiles. 
This can be done dynamicallv as follovi's: 

SQL> ALTER SYSTEM SET DB_CREATE_FII£_DE3T = '/uOa/oradata ' ; 

2. Creating tablespaces 

OnceDB_CREATE_FILE_DEST is set, theDATAFILE clause can be omitted from a 
CREATE TABLE SPACE statement. The da tafile is created in the location specified 
by DB_CREATE_FLLE_DEST by default. For example: 

SQL> CREATE TABLESPACE tbE_2 ; 

When the tbs_2 tablespace is dropped, its datafiles are automatically deleted. 
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Part IV describes the creation and maintenance of schema objects in the Oracle 
Database. It includes the following chapters: 

Chapter 15, "Managing Schema Objects" 

Chapter 17, "Managing Space for Schema Objects" 

Chapter 18, "Managing Tables" 

Chapter 19, "Managing Indexes" 

Chapter 20, "Managing Clusters" 

Chapter 21, "Managing Hash Clusters" 

Chapter 22, "Managing Views, Sequences, and Synonyms" 

Chapter 23, "Repairing Corrupted Data" 
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In this chapter: 

Creating Muhiple Tables and Views in a Single Operation 

Analyzing Tables, Indexes, and Clusters 

Truncating Tables and Clusters 

Enabling and Disabling Triggers 

Managing Integrity Constraints 

Renaming Schema Objects 

Managing Object Dependencies 

Managing Object Name Resolution 

Switching to a Different Schema 

Displaying Information About Schema Objects 

Creating Multiple Tables and Views in a Single Operation 

You can create several tables and views and grant privileges in one operation using 
the CREATE SCHEMA statement. The CREATE SCHEMA statement is useful if you want 
to guarantee the creation of several tables, views, and grants in one operation. If an 
individual table, view or grant fails, the entire statement is rolled back. None of the 
objects are created, nor are the privileges granted. 

Specifically, the CREATE SCHEMA statement can include oi/Jy CREATE TABLE, 
CREATE VIEW, and GRANT statements. You must have the privileges necessary to 
issue the included statements. You are not actually creating a schema, that is done 
when the user is created with a CREATE USER statement. Rather, vou are populating 
the schema. 

The following statement creates two tables and a view that joins data from the two 
tables: 

CREATE SCHEMA AUTHORIZATION scott 
CREATE TABLE dept ( 

deptno HUMBER(3,0) PRIMARY KEY, 

dname VARCHaR2 ( 1 5 ) , 

loc VARCHAR2(25) ) 
CREATE TABLE emp [ 

empno HUMBER(5,0} PRIMARY KEY, 

ename VARCHaR2(15) HOT HULL, 

job VARCHAR2(10) , 

mgr HUMBER(5.0] , 
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hiredate DATE DEFAOLT (sysdate) , 
sal HUMBER(7,2) , 
coram mJMBER{7,2) , 
deptno NUMBER (3,0) NOT NULL 
COHSTRAINT dept_fkey REFERENCES dept) 
CREATE VIEW sales_staff AS 

SELECT empno, enanie, sal, coiirai 

FROM emp 

WHERE deptno =30 

WITH CHECK OPTION CONSTRAINT sales_3taf f_cnEt 

GRANT SELECT ON 3ales_staff TO lnjman_resources ; 

The CREATE SCHEMA statement does not support Oracle Database extensions to the 
ANSI CREATE TABLE and CREATE VIEW statements, including the STORAGE clause. 

See Also: Oracle Database SQL Language Reference for syntax and 
other information about the CREATE SCHEMA statement 



Analyzing Tables, Indexes, and Clusters 

You analyze a schema object (table, index, or cluster) to: 

■ Collect and manage statistics for it 

■ Verify the validity of its storage format 

■ Identify migrated and chained rows of a table or cluster 



Note: Do not use the COMPUTE and ESTIMATE clauses of 
ANALYZE to collect optimizer statistics. These clauses are supported 
for backward compatibilit;'. Instead, use the DBMS_STATS package, 
which lets vou collect statistics in parallel, collect global statistics 
for partitioned objects, and fine tune your statistics collection in 
other ways. The cost-based optimizer, which depends upon 
statistics, will eventually use only statistics that have been collected 
by DBMS_STATS. See Oracle Database PL/SQL Packages and Types 
Reference for more information on the DBMS_STATS package. 

You must use the ANALYZE statement (rather than DBMS_STATS) 
for statistics collection not related to the cost-based, optimizer, such 
as: 

■ To use the VALIDATE or LI ST CHAINED ROWS clauses 

■ To collect information on freelist blocks 

The following topics are discussed in this section: 

. Using DBMS_STATS to CoUect Table and Index Statistics 

■ Validating Tables, Indexes, Clusters, and Materialized Views 

■ Listing Chained Rows of Tables and Clusters 

Using DBMS_STATS to Collect Table and Index Statistics 

You can use the DBMS_STATS package or the ANALYZE statement to gather statistics 
about the phvsical stomge characteristics of a table, index, or cluster. These statistics 
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are stored in the data dictionary and can be used bv the optimizer to choose the most 
efficient execution plan for SQL statements accessing analyzed objects, 

Oracle recommends using the more versatile DBMS_STATS package for gathering 
optimizer statistics, but you must use the ANALYZE statement to collect statistics 
unrelated to the optimizer, such as empty blocks, average space, and so forth. 

The DBMS_STATS package allows both the gathering of statistics, including utilizing 
parallel execution, and the external manipulation of statistics. Statistics can be stored 
in tables outside of the data dictionary, where they can be manipulated without 
affecting the optimizer. Statistics can be copied between databases or backup copies 
can be made. 

The following DBMS_STATS procedures enable the gathering of optimizer statistics: 

■ GATHER_INDEX_STATS 

■ GATHER_TABLE_STATS 

■ GATHER_SCHEMA_STATS 

■ GATHER_DATABASE_STATS 

See Also: 

■ Oracle Database Performance Tuning Guide for information about 
using DBMS_STATS to gather statistics for the optimizer 

■ Oracle Database PL/SQL Packages and Types Reference for a 
description of the DBMS_STATS package 

Validating Tables, Indexes, Clusters, and Materialized Views 

To verify the integritv of the structure of a table, index, cluster, or materialized view, 
use the ANALYZE statement with the VALIDATE STRUCTURE option. If the structure is 
valid, no error is returned. However, if the structure is corrupt, you receive an error 
message. 

For example, in rare cases such as hardware or other svstem failures, an index can 
become corrupted and not perform correctly. When validating the index, you can 
confirm that everv entr}' in the index points to the correct row of the associated table. 
If the index is corrupt, you can drop and re-create it. 

If a table, index, or cluster is corrupt, you should drop it and re-create it. If a 
materialized view is corrupt, perform a complete refresh and ensure that vou have 
remedied the problem. If the problem is not corrected, drop and re-create the 
materialized view. 

The following statement analyzes the emp table; 

MALYZE TABLE emp VALIDATE STRDCTURE; 

You can validate an object and all dependent objects (for example, indexes) by 
including the CASCADE option. The following statement validates the emp table and all 
associated indexes: 

ANALYZE TABLE emp VALIDATE STRDCTURE CASCADE; 

By default the CASCADE option performs a complete validation. Because this operation 
can be resource intensive, you can perform a faster version of the validation bv using 
the FAST clause. This version checks for the existence of corruptions using an 
optimized check algorithm, but does not report details about the corruption. If the 
FAST check finds a corruption, you can then use the CASCADE option without the 
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FAST clause to locate it. The following statement performs a fast validation on the emp 
table and all associated indexes: 

MALYZE TABI£ emp VALIDATE STRUCTURE CASCADE FAST; 

YoLL can specify that vou want to perform structure validation online while DML is 
occurring against the object being validated. There can be a slight performance impact 
when validating with ongoing DML affecting the object, but this is offset by the 
flexibilit}" of being able to perform ANALYZE online. The following statement validates 
the emp table and all associated indexes online: 

AHALYZE TABI£ emp VALIDATE STRUCTURE CASCADE OHLINE; 

See Also: Oracle Database SQL Language Reference for more 
information on the ANALYZE statement 

Listing Chained Rows of Tables and Clusters 

You can took at the chained and migrated rows of a table or cluster using the ANALYZE 
statement with the LI ST CHAINED ROWS clause. The results of this statement are 
stored in a specified table created explicitly to accept the information returned by the 
LIST CHAINED ROWS clause. These results are useful in determining whether you 
have enough room for updates to rows. 

Creating a CHAINED_ROWS Table 

To create the table to accept data returned by an ANALYZE . . . LIST CHAINED ROWS 
statement, execute the UTLCHAIN . SQL or UTLCHNl . SQL script. These scripts are 
provided by the database. They create a table named CHAINED_ROWS in the schema of 
the user submitting the script. 



Note: Your choice of script to execute for creating the 
CHAINED_ROWS table is dependent upon the compatibility level of 
your database and the type of table you are analyzing. See the 
Oracle Database SQL Language Reference for more information. 

After a CHAINED_EOMS table is created, you specify it in the INTO clause of the 
ANALYZE statement. For example, the following statement inserts rows containing 
information about the chained rows in the einp_dept cluster into the CHAINED_ROWS 
table: 

AHALYZE CLUSTER emp_dept LIST CHAINED ROWS INTO CHflINED_ROMS ; 

See Also: 

■ Oracle Database Reference for a description of the 

CHAINED_ROWS table 

■ "Using the Segment Advisor" on page 17-16 for information on 
how the Segment Advisor reports tables with excess row 
chaining. 

Eliminating Migrated or Chained Rows In a Tabie 

You can use the information in the CHAINED_ROWS table to reduce or eliminate 
migrated and chained rows in an existing table. Use the following procedure, 

1 . Use the AMAIYZK statement to collect information about migrated and chained 
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MALYZE TABI£ order_hist LIST CHAINED ROWS; 



2. Quer}' the output table: 



SELECT 
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The output Usts all rows that are either migrated or chained. 

3. If the output table shows that you have many migrated or chained rows, then you 
can eliminate migrated rows by continuing through the following steps: 

4. Create an intermediate table with the same columns as the existing table to hold 
the migrated and chained rows: 

CREATE TABLE irit_order_hiEt 
A3 SELECT * 

FROM order_hist 
WHERE ROWID IH 

(SELECT HEAD_R01ID 
FROM CHAINED_ROWS 
WHERE TABLEJAHE = ' ORDER_HIST' } ; 

5. Delete the migrated and chained rows from the existing table: 

DELETE FROM order_hi3t 
•/IHEKE ROWID IH 

(SELECT HEAD_ROWID 
FROM CHAINED_ROWS 
WHERE TABLE_HAME = 'ORDERJIST' ) ; 

6. Insert the rows of the intermediate table into the existing table: 

INSERT IHTO order.hist 
SELECT * 
FROM int_order_hist; 

7. Drop the intermediate table: 

DROP TABLE in t_order_hi story; 

8. Delete the information collected in step 1 from the output table: 

DELETE FROM CHAIHED_ROWS 

'ffiffiRE TABLE_NAME = ' ORDER_HIST ' ; 

9. Use the ANALYZE statement again, and query the output table. 

Any rows that appear in the output table are chained. You can eliminate chained rows 
onlv by increasing your data block size. It might not be possible to avoid chaining in 
all situations. Chaining is often unavoidable with tables that have a LONG column or 
large CHAR or VARCHAR2 columns. 
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Truncating Tables and Clusters 



You can delete all rows of a table or all rows in a group of clustered tables so that the 
table (or cluster) still exists, but is completely eniptv. For example, consider a table that 
contains monthly data, and at the end of each month, you need to emptv it (delete all 
rows) after archiving its data. 

To delete all rows from a table, vou have the following options: 

■ Use the DELETE statement, 

■ Use the DROP and CREATE statements. 

■ Use the TRUHCATE statement. 

These options are discussed in the following sections 



Using DELETE 



You can delete the rows of a table using the DELETE statement. For example, the 
following statement deletes all rows from the emp table: 

DELETE ETiOM emp; 

If there are many rows present in a table or cluster when using the DELETE statement, 
significant system resources are consumed as the rows are deleted. For example, CPU 
time, redo log space, and undo segment space from the table and any associated 
indexes require resources. Also, as each row is deleted, triggers can be fired. The space 
previously allocated to the resulting emptv table or cluster remains associated with 
that object. With DELETE you can choose which rows to delete, whereas TRUHCATB 
and DROP affect the entire object. 

See Also: Oracle Database SQL Language Reference for syntax and 
other information about the DELETE statement 



Using DROP and CREATE 



You can drop a table and then re-create the table. For example, the following 
statements drop and then re-create the emp table: 

DROP TABLE emp; 

CREATE TABLE emp ( , , . ) ; 

When dropping and re-creating a table or cluster, all associated indexes, integrity 
constraints, and triggers are also dropped, and all objects that depend on the dropped 
table or clustered table are invalidated. Also, all grants for the dropped table or 
clustered table are dropped. 



Using TRUNCATE 



You can delete all rows of the table using the TRUNCATE statement. For example, the 
following statement truncates the emp table: 

TRUNCATE TABLE emp; 

Using the TRUNCATE statement provides a fast, efficient method for deleting all rows 
from a table or cluster A TRUNCATE statement does not generate any undo 
information and it commits immediately. It is a DDL statement and cannot be rolled 
back, A TRUNCATE statement does not affect any structures associated with the table 
being truncated (constraints and triggers) or authorizations. A TRUNCATE statement 
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also specifies whether space currently allocated for the table is returned to the 
containing tablespace after truncation. 

You can truncate anv table or cluster in your own schema, Anv user who has the DROP 
ANY TABLE svsteni privilege can truncate a table or cluster in any schema. 

Before truncating a table or clustered table containing a parent key, all referencing 
foreign keys in different tables must be disabled. A self -referential constraint does not 
have to be disabled. 

As a TRUNCATE statement deletes rows from a table, triggers associated with the table 
are not fired. Also, a TRUNCATE statement does not generate any audit information 
corresponding to DELETE statements if auditing is enabled. Instead, a single audit 
record is generated for the TRUNCATE statement being issued. See the Orach Database 
Security Guide for information about auditing. 

A hash cluster cannot be truncated, nor can tables within a hash or index cluster be 
individuallv truncated. Truncation of an index cluster deletes all rows from all tables 
in the cluster If all the rows must be deleted from an individual clustered table, use 
the DELETE statement or drop and re-create the table. 

The REUSE STORAGE or DROP STORAGE options of the TRUNCATE statement control 
whether space currently allocated for a table or cluster is returned to the containing 
tablespace after truncation. The default option, DROP STORAGE, reduces the number 
of extents allocated to the resulting table to the original setting for MINEXTENTS, Freed 
extents are then returned to the system and can be used by other objects. 

Alternatively, the REUSE STORAGE option specifies that all space currently allocated 
for the table or cluster remains allocated to it. For example, the following statement 
truncates the emp_dept cluster, leaving all extents previously allocated for the cluster 
available for subsequent inserts and deletes: 

TRUMCATE CLUSTER emp_dept REUSE STORAGE; 

The REUSE or DROP STORAGE option also applies to any associated indexes. When a 
table or cluster is truncated, all associated indexes are also truncated. The storage 
parameters for a truncated table, cluster, or associated indexes are not changed as a 
result of the truncation. 

See Also: Oracle Database SQL Language Reference for syntax and 
other information about the TRUNCATE TABLE and TRUNCATE 
CLUSTER statements 



Enabling and Disabling Triggers 



Database triggers are procedures that are stored in the database and activated ("fired" 
when specific conditions occur, such as adding a row to a table. You can use triggers 
to supplement the standard capabilities of the database to provide a highly 
customized database management system. For example, you can create a trigger to 
restrict DML operations against a table, allowing onlv statements issued during 
regular business hours. 

Database triggers can be associated with a table, schema, or database, Thev are 
implicitly fired when: 

■ DML statements are executed (INSERT, UPDATE, DELETE) against an associated 
table 

■ Certain DDL statements are executed (for example: ALTER, CREATE, DROP) on 
objects within a database or schema 
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■ A specified database event occurs (for example: STARTUP, SHUTDOWN, 

SERVERERROR) 

This is not a complete list. See the Oracle Database SQL Language Reference for a full list 
of statements and database events that cause triggers to fire 

Create triggers with the CREATE TRIGGER statement. They can be defined as firing 
BEFORE or AFTER the triggering event, or INSTEAD OF it. The following statement 
creates a trigger scott . emp_permit_changsE on table scott .emp. The trigger 
fires before any of the specified statements are executed, 

(CREATE TRIGGER scott , emp_permit_changes 
BEFORE 

DEI£TE OR IHSEST OR UPDATE 
OH scott, eng) 



pl/sql block 



You can later remove a trigger from the database by issuing the DROP TRIGGER 
statement, 

A trigger can be in either of two distinct modes: 

■ Enabled 

An enabled trigger executes its trigger body if a triggering statement is issued and 
the trigger restriction, if any, evaluates to true. By default, triggers are enabled 
when first created, 

■ Disabled 

A disabled trigger does not execute its trigger body, even if a triggering statement 
is issued and the trigger restriction (if any) evaluates to true. 

To enable or disable triggers using the ALTER TABLE statement, you must own the 
table, have the ALTER object privilege for the table, or have the ALTER ANY TABLE 
svstem privilege. To enable or disable an individual trigger using the ALTER 
TRIGGER statement, you must own the trigger or have the ALTER ANY TRIGGER 
system privilege. 

See Also: 

■ Oracle Database Concepts for a more detaUed description of 
triggers 

■ Oracle Database SQL Language Reference for svntax of the 
CREATE TRIGGER statement 

■ Oracle Database PL/SQL Language Reference for information 
about creating and using triggers 



Enabling Triggers 



You enable a disabled trigger using the ALTER TRIGGER statement with the ENABLE 
option. To enable the disabled trigger named reorder on the inventory table, enter 
the following statement: 

ALTER TRIGGER reorder ENABLE; 
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To enable all triggers defined for a specific table, use the ALTER TABLE statement 
with the ENABLE ALL TRIGGERS option. To enable all triggers defined for the 
INVENTORY table, enter the following statement: 

ALTEK TABLE inventory 

EHABIoE ALL TRIGGERS; 

See Also: Oracle Datnbase SQL Language Reference for syntax and 
other information about the ALTER TRIGGER statement 

Disabling Triggers 

Consider temporarily disabling a trigger if one of the following conditions is true: 

■ An object that the trigger references is not available. 

■ You must perform a large data load and want it to proceed quickly without firing 
triggers. 

■ You are loading data into the table to which the trigger applies. 

You disable a trigger using the ALTER TRIGGER statement with the DISABLE option. 
To disable the trigger reorder on the inventory table, enter the following 
statement: 

ALTER TRIGGER reorder DISABLE; 

You can disable all triggers associated with a table at the same time using the ALTER 
TABLE statement with the DISABLE ALL TRIGGERS option. For example, to disable 
all triggers defined for the inventory table, enter the following statement: 

ALTER TABLE inventory 

DISABLE ALL TRIGGERS; 



Managing Integrity Constraints 



lntegrit^' constraints are rules that restrict the values for one or more columns in a 
table. Constraint clauses can appear in either CREATE TABLE or ALTER TABLE 
statements, and identify the column or columns affected by the constraint and identify 
the conditions of the constraint. 

This section discusses the concepts of constraints and identifies the SQL statements 
used to define and manage integrily constraints. The following topics are contained in 
this section: 

Integrity Constraint States 

Setting Integrity Constraints Upon Definition 

Modifying, Renaming, or Dropping Existing lntegrit\" Constraints 

Deferring Constraint Checks 

Reporting Constraint Exceptions 

Viewing Constraint Information 
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See Also: 



Oracle Database Concepts for a more thorough discussion of 
integrity constraints 

Oracle Database Advanced Application Developer's Guide for 
detailed information and examples of using integrity 
constraints in applications 



Integrity Constraint States 



You can specify that a constraint is enabled (ENABLE) or disabled (DISABLE). If a 
constraint is enabled, data is checked as it is entered or updated in the database, and 
data that does not conform to the constraint is prevented from being entered. If a 
constraint is disabled, then data that does not conform can be allowed to enter the 
database. 

Additionally, vou can specify that existing data in the table must conform to the 
constraint (VALIDATE). Conversely, if you specify NOVALIDATE, you are not ensured 
that existing data conforms. 

An integrity constraint defined on a table can be in one of the following states: 

■ ENABLE, VALIDATE 

■ ENABLE, NOVALIDATE 

■ DI SABLE, VALIDATE 

■ DI SABLE, NOVALIDATE 

For details about the meaning of these states and an understanding of their 
consequences, see the Oracle Database SQL Language Reference. Some of these 
consequences are discussed here. 

Disabling Constraints 

To enforce the rules defined by integrity constraints, the constraints should alwa}'s be 
enabled. However, consider temporarily disabling the integrity constraints of a table 
for the following performance reasons: 

■ When loading large amounts of data into a table 

■ When performing batch operations that make massive changes to a table (for 
example, changing ever}' employee's number by adding 1000 to the existing 
number) 

■ When importing or exporting one table at a time 

In all three cases, temporarily disabling integrity' constraints can improve the 
performance of the operation, especially in data warehouse configurations. 

It is possible to enter data that violates a constraint while that constraint is disabled. 
Thus, you should always enable the constraint after completing any of the operations 
listed in the preceding bullet list. 

Enabling Constraints 

While a constraint is enabled, no row violating the constraint can be inserted into the 
table. How^ever, while the constraint is disabled such a row can be inserted. This row is 
known as an exception to the constraint. If the constraint is in the enable novalidated 
state, violations resulting from data entered while the constraint was disabled remain. 
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The rows that violate the constraint must be either updated or deleted in order for the 
constraint to be put in the validated state. 

You can identify exceptions to a specific integrity constraint while attempting to 
enable the constraint. See "Reporting Constraint Exceptions" on page 16-14. All rows 
violating constraints are noted in an EXCEPTIONS table, which you can examine. 

Enable Novalidate Constraint State 

When a constraint is in the enable novalidate state, all subsequent statements are 
checked for conformity to the constraint. However, any existing data in the table is not 
checked, A table with enable novahdated constraints can contain invalid data, but it is 
not possible to add new invalid data to it. Enabling constraints in the novahdated state 
is most useful in data warehouse configurations that are uploading valid OLTP data. 

Enabling a constraint does not require validation. Enabling a constraint novalidate is 
much faster than enabling and validating a constraint. Also, validating a constraint 
that is alreadv enabled does not require anv DML locks during validation (unlike 
validating a previously disabled constraint). Enforcement guarantees that no 
violations are introduced during the validation. Hence, enabling without validating 
enables you to reduce the downtime tj'pically associated with enabling a constraint. 

Efficient Use of Integrity Constraints: A Procedure 

Using integrity constraint states in the following order can ensure the best benefits: 

1. Disable state, 

2. Perform the operation (load, export, import). 

3. Enable novalidate state. 

4. Enable state. 

Some benefits of using constraints in this order are: 

■ No locks are held, 

■ All constraints can go to enable state concurrently, 

■ Constraint enabling is done in parallel, 

■ Concurrent acti\'itv on table is permitted. 

Setting Integrity Constraints Upon Definition 

When an integrity constraint is defined in a CREATE TABLE or ALTER TABLE 
statement, it can be enabled, disabled, or validated or not validated as determined by 
your specif ication of the ENABLE /DISABLE clause. If the ENABLE /DISABLE clause is 
not specified in a constraint definition, the database automatically enables and 
validates the constraint. 

Disabling Constraints Upon Definition 

The following CREATE TABLE and ALTER TABLE statements both define and disable 
integrity constraints: 

CREATE TABLE emp ( 

empno [nMBER{5) PRIMARY KEY DISABLE, , . , r 

ALTER TABLE emp 

ADD PRIMARY KEY (empno) DISABLE; 
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An ALTER TABLE statement that defines and disables an integrity' constraint never 
fails because of rows in the table that violate the integrity constraint. The definition of 
the constraint is allowed because its rule is not enforced. 

Enabling Constraints Upon Definition 

The following CREATE TABLE and ALTER TABLE statements both define and enable 
integrity constraints: 

CREATE TABLE emp ( 

empno H0MBER{5) CONSTRAIMT emp.pk PRIMflRY KEY, . . . ; 

ALTER TABLE emp 

ADD COHSTRAIHT emp.pk PRIMARY KEY (empno); 

An ALTER TABLE statement that defines and attempts to enable an integritv 
constraint can fail because rows of the table violate the integritv constraint If this case, 
the statement is rolled back and the constraint definition is not stored and not enabled. 

When you enable a UNIQUE or PRIMARY KEY constraint an associated index is 
created. 



Note: An efficient procedure for enabling a constraint that can 
make use of parallelism is described in "Efficient Use of Integrity 
Constraints: A Procedure" on page 16-11. 

See Also: "Creating an Index Associated with a Constraint" on 
page 19-8 

Modifying, Renaming, or Dropping Existing Integrity Constraints 

You can use the ALTER TABLE statement to enable, disable, modify, or drop a 
constraint. When the database is using a UNIQUE or PRIMARY KEY index to enforce a 
constraint, and constraints associated with that index are dropped or disabled, the 
index is dropped, unless vou specif)' otherwise. 

While enabled foreign keys reference a PRIMARY or UNIQUE kev, you cannot disable 
or drop the PRIMARY or UNIQUE key constraint or the index. 

Disabiing Enabled Constraints 

The following statements disable integrit\' constraints. The second statement specifies 
that the associated indexes are to be kept. 

ALTER TABLE dept 

DISABLE COHSTRAIIT dnaine_ukeyr 

ALTER TABLE dept 

DISABLE PRIMARY KEY KEEP INDEX, 
DISABLE UHIQUE {dname, loc) KEEP IHDEX; 

The following statements enable novalidate disabled integrity constraints: 

ALTER TABLE dept 

ENABLE NOVALIDATE COHSTRAINT dname_ukey; 

ALTER TABLE dept 

ENABLE NOVALIDATE PRIMARY KEY, 

ENABLE NOVALIDATE DMIQUE [dname, loc); 
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The following statements enable or validate disabled integrity constraints: 

ALTER TABLE dept 

MODIFY CONSTRAINT dnaiiie_key VALIDATE; 

ALTER TABLE dept 

MODIFY PRIMARY KEY ENABLE NOVALIDATE; 

The following statements enable disabled integrily constraints: 

ALTER TABLE dept 

ENABLE COHSTRAINT diianie_-ukey ; 

ALTER TABLE dept 

ENABLE PRIMARY KEY, 

ENABLE UMIQUE (dname, loc) ; 

To disable or drop a UNIQUE key or PRIMARY KEY constraint and all dependent 
FOREIGN KEY constraints in a single step, use the CASCADE option of the DI SABLE or 
DROP clauses. For example, the following statement disables a PRIMARY KEY 
constraint and any FOREIGN KEY constraints that depend on it: 

ALTER TABLE dept 

DISABLE PRIMARY KEY CASCADE; 

Renaming Constraints 

The ALTER TABLE. . .RENAME CONSTRAINT statement enables you to rename any 
currently existing constraint for a table. The new constraint name must not conflict 
with any existing constraint names for a user. 

The following statement renames the dname_ukeY constraint for table dept: 

ALTER TABLE dept 

RENAME COMSTRAIHT dnarae_ukey TO dname_unikey; 

When you rename a constraint, all dependencies on the base table remain valid. 

The RENAME CONSTRAINT clause provides a means of renaming system generated 
constraint names. 

Dropping Constraints 

You can drop an integritv constraint if the rule that it enforces is no longer true, or if 
the constraint is no longer needed. You can drop the constraint using the ALTER 
TABLE statement with one of the following clauses: 

■ DROP PRIMARY KEY 

■ DROP UNIQUE 

■ DROP CONSTRAINT 

The following two statements drop integritv constraints. The second statement keeps 
the index associated with the PRIMARY KEY constraint: 

ALTER TABLE dept 

DROP UNIQUE (dname, loc) ; 

ALTER TABLE emp 

DROP PRIMARY KEY KEEP IHDEX, 
DROP CONSTRAINT dept_fkey; 
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IfFOREIGH KEYS reference a UHIQUE or PRIMARY KEY, you must include the 
CASCADE CONSTRAINTS clause in the DROP statement, or you cannot drop the 
constraint. 



Deferring Constraint Checks 



When the database checks a constraint, it signals an error if the constraint is not 
satisfied. You can defer checking the validit}' of constraints until the end of a 
transaction. 

When you issue the SET CONSTRAINTS statement, the SET CONSTRAINTS mode 
lasts for the duration of the transaction, or until another SET CONSTRAINTS 
statement resets the mode. 



Notes: 

■ You cannot issue a SET CONSTRAINT statement inside a 
trigger 

■ Deferrable unique and primary keys must use nonunique 
indexes. 



Set All Constraints Deferred 

Within the application being used to manipulate the data, you must set all constraints 
deferred before you actually begin processing an}' data. Use the following DML 
statement to set all deferrable constraints deferred: 

SET COHSTRAIHTS ALL DEFERRED; 



Note: The SET CONSTRAINTS statement applies only to the 
current transaction. The defaults specified when you create a 
constraint remain as long as the constraint exists. The ALTER 
SESSION SET CONSTRAINTS statement applies for the current 
session only. 



Check the Commit (Optionai) 

You can check for constraint violations before committing by issuing the SET 
CONSTRAINTS ALL IMMEDIATE statement just before issuing the COMMIT, If there 
are any problems with a constraint, this statement fails and the constraint causing the 
error is identified. If you commit while constraints are violated, the transaction is 
rolled back and you receive an error message. 



Reporting Constraint Exceptions 



If exceptions exist when a constraint is validated, an error is returned and the integrity' 
constraint remains novalidated. When a statement is not successfully executed because 
integrity constraint exceptions exist, the statement is rolled back. If exceptions exist, 
you cannot validate the constraint until all exceptions to the constraint are either 
updated or deleted. 

To determine which rows violate the integrity' constraint, issue the ALTER TABLE 
statement with the EXCEPTIONS option in the ENABLE clause. The EXCEPTIONS 
option places the rowid, table owner, table name, and constraint name of all exception 
rows into a specified table. 
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You must create an appropriate exceptions report table to accept information from the 
EXCEPTIONS option of the ENABLE clause before enabling the constraint. You can 
create an exception table by executing the UTLEXCPT . SQL script or the 

UTLEXPTl . SQL script. 



Note: Your choice of script to execute for creating the 
EXCEPTIONS table is dependent upon the compatibility level of 
your database and the type of table you are analyzing. See the 
Oracle Database SQL Language Reference for more inf ornaation. 



Both of these scripts create a table named EXCEPTIONS. You can create additional 
exceptions tables with different names by modifying and resubmitting the script. 

The following statement attempts to validate the PRIMARY KEY of the dept table, and 
if exceptions exist, information is inserted into a table named EXCEPTIONS: 

ALTER TABLE dept EHABLE PRIMARY KEY EXCEPTIOHS INTO EXCEPTIONS; 

If duplicate primary kev values exist in the dept table and the name of the PRIMARY 
KEY constraint on dept is sys_c0 610, then the following query will display those 
exceptions: 

SELECT ' FROM EXCEPTIONS; 

The following exceptions are shown: 

fROWID OWNER TABLE.NAME CONSTRAINT 

AAAAZSARBAARBvqAAB SCOTT DEPT SYS_C00510 

AAAAZSARBAARBvqAAG SCOTT DEPT SYS_C00510 

A more informative query would be to join the rows in an exception report table and 
the master table to list the actual rows that violate a specific constraint, as shown in the 
following statement and results: 

SELECT deptno, dnaine, loc FROM dept, EXCEPTIONS 
WHERE EXCEPTIONS, constraint = 'SYS_C00610' 
AND dept,rowid = EXCEPTIONS ,row_id; 

DEPTNO DHAME LOC 



10 ACCOONTIHG NEIfl YORK 

10 RESEARCH DALLAS 

All rows that violate a constraint must be either updated or deleted from the table 
containing the constraint. When updating exceptions, you must change the value 
violating the constraint to a value consistent with the constraint or to a null. After the 
row in the master table is updated or deleted, the corresponding rows for the 
exception in the exception report table should be deleted to avoid confusion with later 
exception reports. The statements that update the master table and the exception 
report table should be in the same transaction to ensure transaction consistency. 

To correct the exceptions in the previous examples, you might issue the following 
transaction: 

UPDATE dept SET deptno = 20 MHERE dnaine = 'RESEARCH',- 
DELETE FROM EXCEPTIOHS WHERE constraint = ' SYS_C00610 ' ; 
COMMIT; 
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When managing exceptions, the goal is to eliminate all exceptions in your exception 
report table. 



Note: While you are correcting current exceptions for a table with 
the constraint disabled, it is possible for other users to issue 
statements creating new exceptions. You can avoid this bv marking 
the constraint ENABLE NOVALIDATE before you start eliminating 
exceptions. 



See Also: Oracle Database Rejerence for a description of the 
EXCEPTIONS table 



Viewing Constraint Information 



Oracle Database provides the following views that enable you to see constraint 
definitions on tables and to identify columns that are specified in constraints: 

View Description 



DBA_CONSTRAItJTS DBA view describes all constraint definitions in the database. 

ALL view describes constraint definitions accessible to current 
user USER view describes constraint definitions owned by the 

USER CONSTRAIHTS current user 



ALL CONSTRAINTS 



DBA_CONS_COLHMHS DBA view describes all columns in the database that are 

,^ ^ ^ , ,^ specified in constraints. ALL view describes onlv those columns 

ALL_CONS_C0LUMMS "^ ui t , lU i ■£■ j ,. ,. „^t.t, 

accessible to current user that are specified in constraints, USER 

USER_CONS_COLUMHS view describes only those columns owned by the current user 

that are specified in constraints. 



See Also: Oracle Database Rejerence contains descriptions of the 
columns in these views 



Renaming Schema Objects 



To rename an object, it must be in your schema. You can rename schema objects in 
either of the following ways: 

■ Drop and re-create the object 

■ Rename the object using the RENAME statement 

If you drop and re-create an object, all privileges granted for that object are lost. 
Privileges must be regranted when the object is re-created. 

Alternatively, a table, view, sequence, or a private synonym of a table, view, or 
sequence can be renamed using the RENAME statement. When using the RENAME 
statement, integritv constraints, indexes, and grants made for the object are carried 
forward for the new name. For example, the following statement renames the 

sales_staf f view: 

RENAME sales_staff TO dept_30; 

Note: You cannot use RENAME for a stored PL/SQL program unit, 
public synonym, index, or cluster To rename such an object, you 
must drop and re-create it. 
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Before renaming a schema object, consider the following effects: 

■ AH views and PL/SQL program units dependent on a renamed object become 
invahd, and must be recompiled before next use, 

■ All synonyms for a renamed object return an error wlien used. 

See Also: Oracle Database SQL Language Reference for syntax of the 
RENAME statement 
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This section provides background information about object dependencies and object 
invalidation, and explains how invalid objects can be revalidated. The following topics 
are inchided: 

■ About Object Dependencies and Object Invalidation 

■ Manually Recompiling Invalid Objects with DDL 

■ Manually Recompiling Invalid Objects with PL/SQL Package Procedures 

About Object Dependencies and Object Invalidation 

Some types of schema objects reference other objects. For example, a view contains a 
query that references tables or other views, and a PL /SQL subprogram might invoke 
other subprograms and might use static SQL to reference tables or views. An object 
that references another object is called a dependent object, and an object being 
referenced is a referenced object. These references are established at compile time, 
and if the compiler cannot resohe them, the dependent object being compiled is 
marked invalid. 

Oracle Database provides an automatic mechanism to ensure that a dependent object 
is always up to date with respect to its referenced objects. When a dependent object is 
created, the database tracks dependencies between the dependent object and its 
referenced objects. When a referenced object is changed in a wav that might affect a 
dependent object, the dependent object is marked invalid. An invalid dependent object 
must be recompiled against the new definition of a referenced object before the 
dependent object can be used. Recompilation occurs automatically when the invalid 
dependent object is referenced. 

It is important to be aware of changes that can invalidate schema objects, because 
invalidation affects applications running on the database. This section describes how 
objects become invalid, how you ciin identify invalid objects, and how vou can 
validate invalid objects. 

Object Invalidation 

In a typical running application, you would not expect to see views or stored 
procedures become invalid, because applications typically do not change table 
structures or change view or stored procedure definitions during normal execution. 
Changes to tables, views, or PL/SQL units typically occur when an application is 
patched or upgraded using a patch script or ad-hoc DDL statements. Dependent 
objects might be left invalid after a patch has been applied to change a set of 
referenced objects. 

Use the follow^ing query to display the set of invalid objects in the database: 

SELECT ob]ect_iiaiQe, objectjype FROM dba_objects 
WHERE status = 'IlVMiID'; 
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The Database Home page in Enterprise Manager displays an alert wlien scliema 
objects become invalid. 

Object invalidation affects applications in tv^fo wavs. First, an invalid object must be 
revalidated before it can be used bv an application. Revalidation adds latencv to 
application execution. If the number of invalid objects is large, the added latency on 
the first execution can be significant. Second, invalidation of a procedure, function or 
package can cause exceptions in other sessions concurrentlv executing the procedure, 
function or package. If a patch is applied when the application is in use in a different 
session, the session executing the application notices that an object in use has been 
invalidated and raises one of the following 4 exceptions: ORA^061, ORA^064, 
ORA-4065 or ORA-4068, These exceptions must be remedied by restarting apphcation 
sessions following a patch. 

You can force the database to recompile a schema object using the appropriate SQL 
statement with the COMPILE clause. See "Manuallv Recompiling Invalid Objects with 
DDL" on page 16-18 for more information. 

If vou know that there are a large number of inviiiid objects, use the UTL_RECOMP 
PL/SQL package to perform a mass recompilation. See "Manuallv Recompiling 
Invalid Objects with PL/SQL Package Procedures" on page 16-18 for details. 

The following are some general rules for the invalidation of schema objects: 

■ Between a referenced object and each of its dependent objects, the database tracks 
the elements of the referenced object that are involved in the dependency. For 
example, if a single-table view selects onlv a subset of columns in a table, onlv 
those columns are involved in the dependency. For each dependent of an object, if 
a change is made to the definition of anv element involved in the dependency 
(including dropping the element), the dependent object is invalidated. Conversely, 
if changes are made onlv to definitions of elements that are not involved in the 
dependency, the dependent object remains valid. 

In many cases, therefore, developers can avoid invalidation of dependent objects 
and unnecessan' extra work for the database if they exercise care when changing 
schema objects, 

■ Dependent objects are cascade invalidalcd. If any object becomes invalid for any 
reason, all of that object's dependent objects are immediately invalidated, 

■ If vou revoke any object privileges on a schema object, dependent objects are 
cascade invalidated. 

See Also: Oracle Daiabase Concepts for more detailed information 
about schema object dependencies 

Manually Recompiling Invalid Objects with DDL 

You can use an ALTER statement to manually recompile a single schema object. For 
example, to recompile package body Pkgl, you would execute the following DDL 
statement: 

ALTER PACKAGE pkgl COMPILE REUSE SETTINGS ; 

See Also: Oiaclc Database SQL Language Refcrcucc for syntax and 
other information about the various ALTER statements 

Manually Recompiling Invalid Objects with PL/SQL Package Procedures 

Following an application upgrade or patch, it is good practice to revalidate invalid 
objects to avoid application latencies that result from on-demand object revalidation, 
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Oracle provides the UTL_RECOMP package to assist in object revalidation. The 
RECOMP_SERIAL procedure recompiles all invalid objects in a specified schema, or all 
invalid objects in the database if you do not supply the schema name argument. The 
RECOMP_PARALLEL procedure does the same, but in parallel, employing multiple 
CPUs, 

Examples 

Execute the following PL/SQL block to revalidate all invalid objects in the database, in 
parallel and in dependency order: 

begin 

utl_recomp . recoinp__parallel [ ) ; 
end; 

You can also revalidate individual invalid objects using the package DBMS_UTILITY. 
The following PL/SQL block revalidates the procedure UPDATE_SALARY in schema 
HR: 

begin 

dbmE_utility. validate! 'HR', ' irPDATE_3ALARY ' , nameEpace=>l) ; 
end; 

The following PL/SQL block revalidates the package body HR . ACCT_MGMT: 

begin 

dbms.utility. validate ( 'HR', 'ACCT_MGMT' , nameEpace=>2) ; 
end; 

See Also: Oracle Database PL/SQL Packages and Types Reference for 
more information on the UTL_RECOMP and DBMS_UTILITY packages. 
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Object names referenced in SQL statements can consist of several pieces, separated bv 
periods. The following describes how the database resolves an object name. 

1. Oracle Database attempts to qualify the first piece of the name referenced in the 
SQL statement. For example, in scott . emp, scott is the first piece. If there is 
onlv one piece, the one piece is considered the first piece. 

a. In the current schema, the database searches for an object whose name 
matches the first piece of the object name. If it does not find such an object, it 
continues with step b. 

b. The database searches for a public synonym that matches the first piece of the 
name. If it does not find one, it continues with step c. 

c. The database searches for a schema whose name matches the first piece of the 
object name. If it finds one, it returns to step b, now using the second piece of 
the name as the object to find in the qualified schema. If the second piece does 
not correspond to an object in the previously qualified schema or there is not a 
second piece, the database returns an error. 

If no schema is found in step c, the object cannot be qualified and the database 
returns an error, 

2. A schema object has been qualified. Any remaining pieces of the name must match 
a valid part of the found object. For example, if scott . emp . deptno is the name, 
scott is qualified as a schema, emp is qualified as a table, and deptno must 
correspond to a column (because emp is a table). If emp is qualified as a package. 



Managing Schema Objects 16-19 



Managing Object Name Resolution 



deptno must correspond to a public constant, variable, procedure, or function of 
that package. 

When global object names are used in a distributed database, either explicitly or 
indirectly within a svnonym, the local database resolves the reference locally. For 
example, it resolves a svnonym to global object name of a remote table. The partially 
resolved statement is shipped to the remote database, and the remote database 
completes the resolution of the object as described here. 

Because of how the database resolves references, it is possible for an object to depend 
on the nonexistence of other objects. This situation occurs when the dependent object 
uses a reference that would be interpreted differently were another object present. For 
example, assume the following: 

■ At the current point in time, the company schema contains a table named emp. 

■ A PUBLIC synonvm named emp is created for company . emp and the SELECT 
privilege for company . emp is granted to the PUBLIC role, 

■ The jward schema does not contain a table or private synonym named emp, 

■ The user jward creates a view in his schema with the following statement: 

CREATE VIEW dept_salaries AS 

SELECT deptno, MIN{sal) , AVG(sal), MAX{Eal) FTiOM emp 
GROUP BY deptno 
ORDER BY deptno; 

When jward creates the dept_3alaries view, the reference to emp is resolved by 
first looking for jward. emp as a table, view, or private svnonym, none of which is 
found, and then as a public svnonym named emp, which is found. As a result, the 
database notes that jward .dept_EalarieE depends on the nonexistence of 

jward . emp and on the existence of public . emp. 

Now assume that jward decides to create a new view named emp in his schema using 
the following statement: 

CREATE Vim emp A3 

SELECT empno, ename, mgr, deptno 
FROM c ompany , emp ; 

Notice that jward . emp does not have the same structure as company, emp. 

As it attempts to resolve references in object definitions, the database internally makes 
note of dependencies that the new dependent object has on "nonexistent" 
objects— schema objects that, if they existed, would change the interpretation of the 
object's definition. Such dependencies must be noted in case a nonexistent object is 
later created. If a nonexistent object is created, all dependent objects must be 
invalidated so that dependent objects can be recompiled and verified and all 
dependent function-based indexes must be marked unusable. 

Therefore, in the previous example, as jward . emp is created, 

jward. dept_salaries is invalidated because it depends on jward. emp. Then 
when jward. dept_EalarieE is used, the database attempts to recompile the view. 
As the database resolves the reference to emp, it finds jward . emp (public .emp is no 
longer the referenced object). Because jward. emp does not have a sal column, the 
database finds errors when replacing the view, leaving it invalid. 

In summary, you must manage dependencies on nonexistent objects checked during 
object resolution in case the nonexistent object is later created. 
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See Also: "Schema Objects and Database Links" on page 29-14 for 
information about name resolution in a distributed database 



Switching to a Different Schema 



The following statement sets the schema of the current session to the schema name 
specified in the statement. 

ALTEE SESSIOM SET aiREENT_SCHEMA = <sche!iid nams> 

In subsequent SQL statements, Oracle Database uses this schema name as the schema 
qualifier when the qualifier is omitted. In addition, the database uses the temporary 
tablespace of the specified schema for sorts, joins, and storage of temporary database 
objects. The session retains its original privileges and does not acquire any extra 
privileges by the preceding ALTER SESSION statement. 

In the following example, provide the password tiger when prompted; 

COMNECT scott 

ALTER SESSIOM SET CUHHENT_SCHEMA = joe; 

SELECT ' FROM eiii>; 

Because emp is not schema-qualified, the table name is resolved under schema j oe. 
But if Scott does not have select privilege on table j oe.emp, then scott carmot 
execute the SELECT statement 

Displaying Information About Schema Objects 

Oracle Database provides a PL/SQL package that enables you to determine the DDL 
that created an object and data dictionarv views that you can use to display 
information about schema objects. Packages and views that are unique to specific 
types of schema objects are described in the associated chapters. This section describes 
views and packages that are generic in nature and apply to multiple schema objects. 

Using a PLySQL Package to Display Information About Schema Objects 

The Oracle-supplied PL/SQL package DBMS_METADATA . GET_DDL lets you obtain 
metadata (in the form of DDL used to create the object) about a schema object. 

See Also: Oracle Database PL/SQL Packages and Types Reference for 
a description of PL/SQL packages 

Example: Using the DBMS_METADATA Package 

The DBMS_METADATA package is a powerful tool for obtaining the complete definition 
of a schema object It enables vou to obtain all of the attributes of an object in one pass. 
The object is described as DDL that can be used to (rejcreate it. 

In the following statements the GET_DDL function is used to fetch the DDL for all 
tables in the current schema, filtering out nested tables and overflow segments. The 
SET_TEAWSFOEM_PAEAM (with the handle value equal to 

DBMS_METADATA.SESSIOW_TEAWSEOEM meaning "for the current session") is used to 
specifv that storage clauses are not to be returned in the SQL DDL. Afterwards, the 
session-level transform parameters are reset to their defaults. Once set, transform 
parameter values remain in effect until specifically reset to their defaults, 

EKECDTE DBMS_METaDATA.SET_TRAHSFORH_PRRftM( 

DBHS_METADATA.SESSI0[J_TRAKSFORM, 'STORAGE' , false] ; 
SELECT DBMS_METADATA.GET_DDL( 'TABLE' ,u. tablejame] 

Managing Schema Objects 16-21 



Displaying Information About Schema Objects 



FROM USER_ALL_TABLES u 
IHESE u.nesbed='HO' 

AND (u.iot_type is null or u.iot_bYpe= ' lOT' ) ; 
EXECUTE DBHS_METaDATA.SET_TRMSFORH_PSHftM( 

DBHS_METADATA.SESSIOH_TRAHSFDRM, 'DEFAULT' ) ; 

The output from DBMS_METADATA . GET_DDL is a LONG datatype. When using 
SQL'Plus, vour output may tie truncated by default. Issue tlie following SQL'Plus 
command before issuing the DBMS_METADATA . GET_DDL statement to ensure that 
your output is not truncated: 

SQL> SET LONG 9999 

See Also: Oracle XML Developer's Kit Programmer's Guide for 
detailed information and further examples relating to the use of the 

DBMS_METADATA package 

Schema Objects Data Dictionary Views 

These views display general information about schema objects: 



View Description 


DBA_OBJECTS 
ALL_OBJECTS 

USER_OBJECTS 


DBA view describes all schema objects in the database. ALL view 
describes objects accessible to current user. USER view describes 
objects owned by the current user 


DBA_CATALOG 
ALL_CATALOG 

USER_CATALOG 


List the name, type, and owner (USER view does not display 
owner) for all tables, views, synonyins, and sequences in the 

database. 


DBA_DEPENDENC LES 
ALL_DEPENDENC IE3 
USER_DEPEHDEHC lES 


List all dependencies between procedures, packages, functions, 
package bodies, and triggers, including dependencies on views 
without any database links. 



See Also: Oracle Database Reference for a complete description of 
data dictionary views 

The following are exam.ples of using some of these views: 

■ Example 1: Displaying Schema Objects By Type 

■ Example 2: Displaying Dependencies of Views and Synonvms 

Example 1 : Displaying Schema Objects By Type 

The following query lists all of the objects owned by the user issuing the query: 

SELECT OBJECT_HAME, 0BJECT_1^PE 
FROM USER_OB JECTS ; 

The following is the quer;' output: 

OBJECT NAME OBJECT TYPE 



MP DEPT 


CLUSTER 


EMP 


TABLE 


DEPT 


TABLE 


EMP DEPT INDEX 


INDEX 



16-22 Oracle Database Administrator's Guide 



Displaying Inlormation About Schema Objects 



PUBLIC_EMP SYHOIJYH 

EMP_MGR VIEW 

Example 2: Displaying Dependencies of Views and Synonyms 

When you create a view or a synonym, the view or synonvm is based on its 
underlying base object. The ALL_DEPENDENCIES, USER_DEPENDENCIES, and 
DBA_DEPENDENCIES data dictionary views can be used to reveal the dependencies for 
a view. The ALL_SYNONYMS, USER_SYNONYMS, and DBA_SYNOWYMS data dictionary 
views can be used to list the base object of a synonym. For example, the following 
query lists the base objects for the synonyms created by user jward: 

SELECT TABLE_OWNER, TABLE_NME, SYNONYM_HME 
FROM DBA_3YM0MYMS 
WHERE OlvTER = ' JMARD ' ; 

The following is the query output: 

TABLE OWKER TABLE NAME SYMONYM NAME 



SCOTT DEPT DEPT 

SCOTT EMP EMP 
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In this chapter: 

Managing Tablespace Alerts 

Managing Space in Data Blocks 

Managing Storage Parameters 

Managing Resumable Space Allocation 

Reclaiming Wasted Space 

Understanding Space Usage of Datatypes 

Displaying Information About Space Usage for Schema Objects 

Capacit\' Planning for Database Objects 



Managing Tablespace Alerts 



Oracle Database provides proactive help in managing disk space for tablespaces by 
alerting you when available space is running low. Two alert thresholds are defined by 
default: ivaming and crilical. The warning threshold is the limit at which space is 
beginning to run low. The critical threshold is a serious limit that warrants your 
immediate attention. The database issues alerts at both thresholds. 

There are two ways to specify alert thresholds for both locally managed and dictionary 
managed tablespaces: 

■ By percent full 

For both warning and critical thresholds, when space used becomes greater than 
or equal to a percent of total space, an alert is issued. 

■ By free space remaining (in kilobytes (KB)) 

For both warning and critical thresholds, when remaining space falls below an 
amount in KB, an alert is issued. Free- space-remaining thresholds are more useful 
for very large tablespaces. 

Alerts for locally managed tablespaces are server- gene rated. For dictionary managed 
tablespaces. Enterprise Manager provides this functionalit\'. See "Monitoring with 
Server-Generated Alerts" on page 7 A for more information. 

New tablespaces are assigned alert thresholds as follows: 

■ Locally managed tablespace — When you create a new locally managed 
tablespace, it is assigned the default threshold values defined for the database, A 
newly created database has a default of SB^u full for the warrung threshold and 
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97% full for the critical threshold. Defaults for free space remaining thresholds for 
a new database are both zero (disabled). You can change these database defaults, 
as described later in this section. 

Dictionary managed tablespace — When vou create a new dictionary managed 
tablespace, it is assigned the threshold values that Enterprise Manager lists for "All 
others" in the metrics categories "Tablespace Free Space (MB) (dictionary 
managed)" and "Tablespace Space Used (%) (dictionary managed)," You change 
these values on the Metric and Policy Settings page. 

Note: In a database that is upgraded from version 9,x or earlier to 
10, X, database defaults for all locally managed tablespace alert 
thresholds are set to zero. This setting effecti\'ely disables the alert 
mechanism to avoid excessive alerts in a newlv migrated database. 



Setting Alert Thresholds 



For each tablespace, you can set just percent-full thresholds, just free-space-remaining 
thresholds, or both types of thresholds simultaneously. Setting either type of threshold 
to zero disables it. 

The ideal setting for the warning threshold is one that issues an alert early enough for 
you to resolve the problem before it becomes critical. The critical threshold should be 
one that issues an alert still early enough so that you can take immediate action to 
avoid loss of service. 

To set alert threshold values; 

■ For locallv managed tablespaces, use Enterprise Manager (see Oradc Database 2 
Day DBA for instructions) or the DBMS_SERVER_ALERT . SET_THRESHOLD 
package procedure (see Oracle Database PL/SQL Packages and Types Reference for 
usage details), 

■ For dictionary managed tablespaces, use Enterprise Manager See Oracle Database 2 
Day DBA for instructions. 

Example — Locally Managed Tablespace 

The following example sets the free-space-remaining thresholds in the USERS 
tablespace to 10 MB (warning) and 2 MB (critical), and disables the percent-full 
thresholds. 

BEGIH 

DBMS_3ERVER_ALERT . SET_THRESHOLD ( 

metric3_id => DBMS_SERVER_ALERT.TABLESPACE_BYT_FREE, 

warning_operator => DBMS_SERUER_ALERT.OPERATOR_LE, 

warning_value => '10240', 

critical_operator => DBMS_SERUER_ALERT.OPERATOR_LE, 

critical_value => ' 2 048' . 

observation_period => 1, 

consec"utive_occurreiiceE => 1, 

instance_nanie => HULL, 

object_type => DBMS_SERUER_ALERT . OB JECT_TYPE_TABLE3 PACE , 

object_riame => 'USERS'); 

DBMS_SERVER_ALERT . SET_THRESHOLD { 

iiietrics_id => DBHS_SERVER_ALERT.TABLESPACE_PCT_FULL, 

warning_operator => DBHS_SERVER_ALERT.OPERATOR_GT, 

warning_value => ' ' , 

critical_operator => DBMS_SERUER_ALERT.OPERATOR_GT, 
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critical_value => 'D', 

observation_period. => 1, 

CDnEec"utive_occurrsnceE => 1, 

instaiice_nanie => NULL, 

object_type => DBHS_SERVER_M,ERT.OBJECT_T¥PE_TaBLESPAnE, 

object_naiQe => 'USERS'); 
END; 
/ 



Note: When setting non-zero values ior percent-full tKresholds, use 
the greater- Uian-or-equal-to operator, OPERATOR_GE. 

Restoring a Tablespace to Database Default Thresholds 

After explicitly setting values for locnllv managed tablespace alert thresholds, you can 
cause the values to revert to the database defaults by setting them to NULL with 

DBM3_SERVER_ALERT . SET_THRESHOLD. 

Modifying Database Default Thresholds 

To modify database default thresholds for locally managed tablespaces, invoke 
DBMS_SERVER_ALERT. SET_THRESHOLD as shown in the previous example, but set 
ob j ect_nai[ie to NULL. All tablespaces that use the database default are then 
switched to the new default. 



Viewing Aierts 



You view alerts bv accessing the home page of Enterprise Manager Database Control, 
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Limitations 



You can also view alerts for locallv managed tablespaces with the 
DBA_OUTSTAWDIWG_ALERTS view. See "Server-Generated Alerts Data Dictionary 
Views" on page 7-6 for more information. 



Thieshold-based alerts have the following limitations; 

■ Alerts are not issued for locallv managed tablespaces that are offhne or in 
read-onlv mode. However, the database reactivates the alert system for such 
tablespaces after they become read/write or available. 

■ When you take a tablespace offline or put it in read-only mode, you should disable 
the alerts for the tablespace bv setting the thresholds to zero. You can then 
reenable the alerts by resetting the thresholds when the tablespace is once again 
online and in read/write mode. 
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See Also: 



"Monitoring with Server-Generated Alerts" on page 7A for 
additional information on server- genera ted alerts in general 

Oracle Database PL/SQL Packages and Types Reference for 
information on the procedures of the DBMS_SERVER_ALEHT 
package and how to use them 

Oracle Database Performance Tuning Guide for information on 
using the Automatic Workload Repository to gather statistics 
on space usage 

"Reclaiming Wasted Space" on page 17-15 for various ways to 
reclaim space that is no longer being used in the tablespace 

"Purging Objects in the Recycle Bin" on page 18-47 for 
information on reclaiming recycle bin space 



Managing Space in Data Blocks 

The following topics are contained in this section: 
. Specifying the INITRANS Parameter 



See Also: 

■ Oracle Database Concepts for more information on data blocks 

■ Oracle Database SQL Language Reference for syntax and other 
details of the INITRANS physical attributes parameters 



Specifying the INITRANS Parameter 



INITRANS specifies the number of update transaction entries for which space is 
initially reser\'ed in the data block header Space is reserved in the headers of all data 
blocks in the associated segment. 

As multiple transactions concurrently access the rows of the same data block, space is 
allocated for each update transaction entry in the block. Once the space reserved by 
INITRANS is depleted, space for additional transaction entries is allocated out of the 
free space in a block, if available. Once allocated, this space effectively becomes a 
permanent part of the block header 

Note: In earlier releases of Oracle Database, the MAXTRANS 
parameter limited the number of transaction entries that could 
concurrently use data in a data block. This parameter has been 
deprecated, Oracle Database now automatically allows up to 255 
concurrent update transactions for any data block, depending on 
the available space in the block. 

The database ignores MAXTRANS when specified by users only for 
new objects created when the COMPATIBLE initialization parameter 
is set to 10.0.0 or greater 



You should consider the following when setting the INITRANS parameter for a 
schema object; 

■ The space you would like to reserve for transaction entries compared to the space 
you would reserve for database data 
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■ The number of concurrent transactions that are likely to touch the same data 
blocks at any given time 

For example, if a table is very large and only a small number of users simultaneously 
access the table, the chances of multiple concurrent transactions requiring access to the 
same data block is low. Therefore, INITRAWS can be set low, especially if space is at a 
premium in the database. 

Alternatively, assume that a table is usually accessed bv many users at the same time. 
In this case, you might consider preallocating transaction entry space by using a high 
INITRANS. This eliminates the overhead of having to allocate transaction entry space, 
as required when the object is in use. 

In general, Oracle recommends that you not change the value of INITRANS from its 
default. 

Managing Storage Parameters 

This section describes the storage parameters that vou can specify for schema object 
segments to tell the database how to store the object in the database. Schema objects 
include tables, indexes, partitions, clusters, materialized views, and materialized view 
logs 

The following topics are contained in this section: 

Identifying the Storage Parameters 

Specifying Storage Parameters at Object Creation 

Setting Storage Parameters for Clusters 

Setting Storage Parameters for Partitioned Tables 

Setting Storage Parameters for Index Segments 

Setting Storage Parameters for LOBs, Varravs, and Nested Tables 

Changing Values of Storage Parameters 

Understanding Precedence in Storage Parameters 

Identifying the Storage Parameters 

storage parameters determine space allocation for objects when their segments are 
created in a tablespace. Not all storage parameters can be specified for everv type of 
database object, and not all storage parameters can be specified in both the CREATE 
and ALTER statements. Storage parameters for objects in locally managed tablespaces 
are supported mainly for backward compatibiUt\'. 

The Oracle Database server manages extents for locally managed tablespaces. If you 
specified the UNIFORM clause when the tablespace was created, then the database 
creates all extents of a uniform size that you specified (or a default size) for any objects 
created in the tablespace. If you specified the AUTOALLOCATE clause, then the 
database determines the extent sizing policy for the tablespace. So, for example, if vou 
specific the INITIAL clause when you create an object in a locally managed tablespace 
you are telling the database to preallocate at least that much space. The database then 
determines the appropriate number of extents needed to allocate that much space. 

Table 17—1 contains a brief description of each storage parameter For a complete 
description of these parameters, including their default, minimum, and maximum 
settings, see the Oracle Database SQL Language Reference. 
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Table 17-1 Object Storage Parameters 



Parameter 

INITIAL 



MINEXTENTS 



BUFFER POOL 



Description 



In a tablespace that is specified as EXTENT MMTAGEHEHT LOCAL, 
the database uses the value of IHITIAL with the extent size for the 
tablespace to determine the initial amount of space to reserve for the 
object. For example, in a uniform locally managed tablespace with 
5M extents, if you specify an IHITIAL value of IM, then the 
database must allocate one 5M extent. If the extent size of the 
tablespace is smaller than the value of INITIAL, then the initial 
amount of space allocated will in fact be more than one extent. 

In a tablespace that is specified as EXTENT MAMAGEMEHT LOCAL, 
MINEXTENTS is used to compute the initial amount of space that is 
allocated. The initial amount of space that is allocated is equal to 
INITIAL •MIHEXTEHTS.Thereafter it is set to 1 (as seen in the 

DBA_SEGMEHTS view). 

Defines a default buffer pool [cachej tor a schema object. For 
information on the use of this parameter, see Orack Database 
Performance Tuning Guide. 



Specifying Storage Parameters at Object Creation 

At object creation, vou can specify storage parameters for each individual schema 
object. These parameter settings override anv default storage settings. Use the 
STORAGE clause of the CREATE or ALTER statement for specifying storage parameters 
for the individual object. 

Setting Storage Parameters for Clusters 

Use the STORAGE clause of the CREATE TABLE or ALTER TABLE statement to set the 
storage parameters for non-clustered tables. 

In contrast, set the storage parameters for the data segments of a cluster using the 
STORAGE clause of the CREATE CLUSTER or ALTER CLUSTER statement, rather than 
the individual CREATE or ALTER statements that put tables into the cluster. Storage 
parameters specified when creating or altering a clustered table are ignored. The 
storage parameters set for the cluster override the table storage parameters. 

Setting Storage Parameters for Partitioned Tables 

With partitioned tables, vou can set default storage parameters at the table level. When 
creating a new partition of the table, the default storage parameters are inherited from 
the table level (unless vou specify them for the individual partition). If no storage 
parameters are specified at the table level, then they are inherited from the tablespace. 

Setting Storage Parameters for Index Segments 

Storage parameters for an index segment created for a table index can be set using the 
STORAGE clause of the CREATE INDEX or ALTER INDEX statement. 

Storage parameters of an index segment created for the index used to enforce a 
primary key or unique key constraint can be set in either of the following ways: 

■ In the ENABLE ... USING INDEX clause of the CREATE TABLE or ALTER TABLE 

statement 

■ In the STORAGE clause of the ALTER INDEX statement 
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Setting Storage Parameters for LOBs, Varrays, and Nested Tables 

A table or materialized view can contain LOB, varrav, or nested table column types. 
These entities can be stored in their own segments. LOBs and varrays are stored in LOB 
segments, while a nested table is stored in a storage table. You can specify a STORAGE 
clause for these segments that will override storage parameters specified at the table 
level. 

See Also: 

■ Oracle Database ScciireFiks and Large Objects Developer's Guide 
for more information about LOBs 

■ Oracle Database Objeci-Rclational Developer's Guide for more 
information about \'arravs and nested tables 



Changing Values of Storage Parameters 

You can alter default storage parameters for tablespaces and specific storage 
parameters for individual objects if vou so choose. Default storage parameters can be 
reset for a tablespace; however, changes affect only new objects created in the 
tablespace or new extents allocated for a segment. As discussed previously, vou 
cannot specify default storage parameters for locally managed tablespaces, so this 
discussion does not apply. 

The INITIAL and MINEXTENTS storage parameters cannot be altered for an existing 
table, cluster, index. If only NEXT is altered for a segment, the next incremental extent 
is the size of the new NEXT, and subsequent extents can grow by PCTINCEEASE as 
usual. 

If both NEXT and PCT INCREASE are altered for a segment, the next extent is the new 
value of NEXT, and from that point forward, NEXT is calculated using PCTINCREASE 
as usual. 

Understanding Precedence in Storage Parameters 

Starting with default values, the storage parameters in effect for a database object at a 
given time are determined by the following, listed in order of precedence (where 
higher numbers take precedence over lower numbers): 

1. Oracle Database default values 

2. DEFAULT STORAGE clause of CREATE TABLESPACE statement 

3. DEFAULT STORAGE clause of ALTER TABLESPACE statement 

4. STORAGE clause of CREATE [TABLE I CLUSTER I MATERIALIZED VIEW I 
MATERIALIZED VIEW LOG I INDEX] statement 

5. STORAGE clauseof ALTER [TABLE I CLUSTER I MATERIALIZED VIEW I 
MATERIALIZED VIEW LOG I INDEX] statement 

Any storage parameter specified at the object level o\'errides the corresponding option 
set at the tablespace level. When storage parameters are not explicitly set at the object 
level, they default to those at the tablespace level. When storage parameters are not set 
at the tablespace level, Oracle Database system defaults apply. If storage parameters 
are altered, the new options apply only to the extents not yet allocated. 



Note: The storage parameters for temporary segments always use 
the default storage param.eters set for the associated tablespace. 
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Managing Resumable Space Allocation 



Oracle Database provides a means for suspending, and later resuming, the execution 
of large database operations in the event of space allocation failures. This enables vou 
to take corrective action instead of the Oracle Database server returning an error to the 
user After the error condition is corrected, the suspended operation automatically 
resumes. This feature is called resumable space allocation. The statements that are 
affected are called resumable statements. 

This section contains the following topics: 

Resumable Space Allocation Overview 

Enabling and Disabling Resumable Space Allocation 

Detecting Suspended Statements 

Operation-Suspended Alert 

Resumable Space Allocation Example: Registering an AFTER SUSPEND Trigger 



Resumable Space Allocation Overview 



This section provides an overview of resumable space allocation. It describes how 
resumable space allocation works, and specifically defines qualifying statements and 
error conditions. 

How Resumable Space Allocation Works 

The following is an overview of how resumable space allocation works. Details are 
contained in later sections, 

1. A statement executes in a resumable mode onlv if its session has been enabled for 
resumable space allocation by one of the following actions: 

■ The RESUMABLE_TIMEOUT initialization parameter is set to a nonzero value, 

■ The ALTER SESSION ENABLE RESUMABLE statement is issued, 

2. A resumable statement is suspended when one of the following conditions occur 
(these conditions result in corresponding errors being signalled for non-resumable 
statements): 

■ Out of space condition 

■ Maximum extents reached condition 

■ Space quota exceeded condition, 

3. When the execution of a resumable statement is suspended, there are mechanisms 
to perform user supplied operations, log errors, and to query the status of the 
statement execution. When a resumable statement is suspended the following 
actions are taken: 

■ The error is reported in the alert log, 

■ The system issues the Resumable Session Suspended alert, 

■ If the user registered a trigger on the AFTER SUSPEND svstem event, the user 
trigger is executed, A user supplied PL /SQL procedure can access the error 
message data using the DBMS_RESUMABLE package and the DBA_ or 

USER_EESUMABLE view, 

4. Suspending a statement automatically results in suspending the transaction. Thus 
all transactional resources are held through a statement suspend and resume. 
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5. When the error condition is resolved (for example, as a result of user intervention 
or perhaps sort space released by other queries), the suspended statement 
automatically resumes execution and the Resumable Session Suspended alert is 
cleared. 

6. A suspended statement can be forced to throw the exception using the 
DBMS_RESUMABLE .ABORT ( ) procedure. This procedure can be called by a DBA, 
or by the user who issued the statement. 

7. A suspension time out inter\'al is associated with resumable statements. A 
resumable statement that is suspended for the timeout interval (the default is two 
hours) wakes up and returns the exception to the user. 

8. A resumable statement can be suspended and resumed multiple times during 
execution. 

What Operations are Resumable? 

The following operations are resumable; 

■ Queries 

SELECT statements that run out of temporary space {for sort areas) are candidates 
for resumable execution. When using OCl, the calls OCI Stmt Execute ( ) and 

OCIStmtFetch ( ) are candidates. 

. DML 

INSERT, UPDATE, and DELETE statements are candidates. The interface used to 
execute them does not matter; it can be OCl, SQLJ, PL/SQL, or another interface. 
Also, INSERT INTO . . . SELECT from external tables can be resumable. 

■ Import/Export 

As for SQL*Loader, a command line parameter controls whether statements are 
resumable after recoverable errors. 

. DDL 

The following statements are candidates for resumable execution: 

- CREATE TABLE ... AS SELECT 

- CREATE INDEX 

- ALTER INDEX ... REBUILD 

- ALTER TABLE ... MOVE PARTITION 

- ALTER TABLE ... SPLIT PARTITION 

- ALTER INDEX ... REBUILD PARTITION 

- ALTER INDEX ... SPLIT PARTITION 

- CREATE MATERIALI ZED VIEW 

- CREATE MATERIALIZED VIEW LOG 

What Errors are Correctable? 

There are three classes of correctable errors: 

■ Out of space condition 
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The operation cannot acquire anv more extents for a table/index/temporar}' 
segment/undo segment /cluster /LOB /table partition /index partition in a 
tabiespace. For example, the following errors fall in this category: 

ORA-1553 "unable to extend table ... in tabiespace ... 
ORA-1554 unable to extend index ... in tabiespace ... 

■ Maximum extents reached condition 

The number of extents in a table/index/temporarv segment/undo 
segment /cluster /LOB /table partition/ index partition equals the maximum 
extents defined on the object. For example, the following errors fall in this 
category: 

ORA-1531 max # extents . . . reached in table . . . 
ORA-1554 max # extents ... reached in index ... 

■ Space quota exceeded condition 

The user has exceeded his assigned space quota in the tabiespace. Specifically, this 
is noted by the following error: 

OEA-1536 space quote exceeded for tabiespace string 

Resumable Space Allocation and Distributed Operations 

In a distributed environment, if a user enables or disables resumable space allocation, 
or if you, as a DBA, alter the RESUMABLE_TIMEOUT initialization parameter, only the 
local instance is affected. In a distributed transaction, sessions or remote instances are 
suspended only if RESUMABLE has been enabled in the remote instance. 

Paraliei Execution and Resumable Space Allocation 

In parallel execution, if one of the parallel execution server processes encounters a 
correctable error, that server process suspends its execution. Other parallel execution 
server processes will continue executing their respective tasks, until either thev 
encounter an error or are blocked (directly or indirectly) b}' the suspended ser\'er 
process. When the correctable error is resolved, the suspended process resumes 
execution and the parallel operation continues execution. If the suspended operation is 
terminated, the parallel operation aborts, throwing the error to the user 

Different parallel execution sen'er processes may encounter one or more correctable 
errors. This may result in firing an AFTER SUSPEND trigger multiple times, in parallel 
Also, if a parallel execution server process encounters a non-correctable error while 
another parallel execution server process is suspended, the suspended statement is 
immediately aborted. 

For parallel execution, everv parallel execution coordinator and server process has its 

ownentry in theDBA_or USER_RESUMABLE view. 

Enabling and Disabling Resumable Space Allocation 

Resumable space allocation is only possible when statements are executed within a 
session that has resumable mode enabled. There are two means of enabling and 
disabling resumable space allocation. You can control it at the system level with the 
RESUMABLE_TIMEOUT initialization parameter, or users can enable it at the session 
level using clauses of the ALTER SESSION statement. 
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Note: Because suspended statements can hold up some system 
resources, users must be granted the RESUMABLE system privilege 
before they are allowed to enable resumable space allocation and 
execute resumable statements. 



Setting the RESUMABLE_TIMEOUT Initialization Parameter 

You can enable resumable space allocation svstem wide and specify a timeout interval 
by setting the RESUMABLE_TIMEOUT initialization parameter. For example, the 
following setting of theRESUMABLE_TIMEOUT parameter in the initialization 
parameter file causes all sessions to initially be enabled for resumable space aUocation 
and sets the timeout period to 1 hour: 

RE3UI>1ABLE_TIMEOOT = 3600 

If this parameter is set to 0, then resumable space allocation is disabled initially for all 
sessions. This is the default. 

You can use the ALTER SYSTEM SET statement to change the value of this parameter 
at the system level. For example, the following statement will disable resumable space 
allocation for all sessions; 

ALTER SYSTEM SET HESIMflBLE_TIMEOnT= ; 

Within a session, a user can issue the ALTER SESSION SET statement to set the 
RESUMABLE_TIMEOUT initialization parameter and enable resumable space allocation, 
change a timeout value, or to disable resumable mode. 

Using ALTER SESSION to Enable and Disable Resumable Space Allocation 

A user can enable resumable mode for a session, using the following SQL statement: 

ALTER SESSIOH EHABLE RESUMABLE; 

To disable resumable mode, a user issues the following statement: 

ALTER SESSIDH DISABLE RESUMABLE; 

The default for a new session is resumable mode disabled, unless the 
RESUMaBLE_TIMEOUT initialization parameter is set to a nonzero value. 

The user can also specifv a timeout interval, and can provide a name used to identify a 
resumable statement. These are discussed separately in following sections. 

See Also: "Using a LOGON Trigger to Set Default Resumable 
Mode" on page 17-12 

Specifying a Timeout Interval A timeout period, after which a suspended statement will 
error if no intervention has taken place, can be specified when resumable mode is 
enabled. The following statement specifies that resumable transactions will time out 
and error after 3600 seconds: 

ALTER SESSIDH ENABLE RESUMABLE TIMEOUT 3600; 

The value of TIMEOUT remains in effect until it is changed by another ALTER 
SESSION ENABLE RESUMABLE statement, it is changed by another means, or the 
session ends. The default timeout interval when using the ENABLE RESUMABLE 
TIMEOUT clause to enable resumable mode is 7200 seconds. 
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See Also: "Setting the RESUMABLE_TIMEOUT Initialization 
Parameter" on page 17-11 for other methods of changing the 
timeoLit interval for resumable space allocation 

Naming Resumable Statements Resumable statements can be identified by name. The 
following statement assigns a name to resumable statem.ents: 

ALTER SESSION ENABLE RESUMABLE TIMEOUT 3600 HAME 'insert into table'; 

The NAME value remains in effect until it is changed by another ALTER SESSION 
ENABLE RESUMABLE statement, or the session ends. The default value for NAME is 
'User usern^me(userid). Session sessionid, Instance instanceid'. 

The name of the statement is used to identify the resumable statement in the 

DBA_RESUMABLE and USER_RESUMABLE views. 

Using a LOGON Trigger to Set Default Resumable Mode 

Another method of setting default resumable mode, other than setting the 
RESUMABLE_TIMEOUT initialization parameter, is that you can register a database 
level LOGON trigger to alter a user's session to enable resumable and set a timeout 
interval. 

Note: If there are multiple triggers registered that change default 
mode and timeout for resumable statements, the result will be 
unspecified because Oracle Database does not guarantee the order 
of trigger invocation. 



Detecting Suspended Statements 



When a resumable statement is suspended, the error is not raised to the client. In order 
for corrective action to be taken, Oracle Database provides alternative methods for 
notif\'ing users of the error and for providing information about the circumstances. 

Notifying Users: The AFTER SUSPEND System Event and Trigger 

When a resumable statement encounter a correctable error, the system internally 
generates the AFTER SUSPEND svstem event. Users can register triggers for this event 
at both the database and schema level. If a user registers a trigger to handle this 
system event, the trigger is executed after a SQL statement has been suspended, 

SQL statements executed within a AFTER SUSPEND trigger are alwavs non-resumable 
and are alwavs autonomous. Transactions started within the trigger use the SYSTEM 
rollback segment. These conditions are imposed to overcome deadlocks and reduce 
the chance of the trigger experiencing the same error condition as the statement. 

Users can use the USER_RESUMABLE or DBA_RESUMABLE views, or the 
DBMS_RESUMABLE . SPACE_ERROR_INFO function, within triggers to get information 
about the resumable statements. 

Triggers can also call the DBMS_RESUMABLE package to terminate suspended 
statements and modify resumable timeout values. In the following example, the 
default svstem timeout is changed bv creating a system wide AFTER SUSPEND trigger 
that calls DBMS_RESUMABLE to set the timeout to 3 hours: 

CREATE OR REPLACE TRIGGER resuiiiable_default_timeout 
AFTER SUSPEND 
OH DATABASE 
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EEGIH 

DBMS_RESUMftBLE.SET_TIMEOUT(10800) ; 
EKD; 

See Also: Oracle Database PL/SQL Language Reference for 
mformation about triggers and system events 

Using Views to Obtain Information About Suspended Statements 

The following views can be queried to obtain information about the status of 
resumable statements: 



View 



Description 



DBA_EESUMABLE 
DSER RESUMABLE 



These views contain rows for all currently executing or suspended 
resumable statements. They can be used by a DBA, AFTER 
3USPEHD trigger, or another session to monitor the progress of, or 
obtain specific information about, resumable statements. 



V$SESSIOM_WAIT When a statement is suspended the session invoking the statement is 
put into a wait state. A row is inserted into this view for the session 
with the EVEHT column containing "statement suspended, wait error 
to be cleared". 



See Also: Oracle Database Reference for specific information about 
the columns contained in these views 

Using tlie DBMS_RESUMABLE Pacltage 

The DBMS_RESUMABLE package helps control resumable space allocation. The 

following procedures can be invoked: 



Procedure 



Description 



ABORT (sessionID) 



This procedure aborts a suspended resumable statement. The 
parameter sessionID is the session ID in which the statement 
is executing. For parallel DML/DDL, sessionID is any 
session ID which participates in the parallel DML/DDL. 

Oracle Database guarantees that the ABORT operation always 
succeeds. It maybe called either inside or outside of the AFTER 
3USPEHD trigger 

The caller of ABORT must be the owner of the session with 
sessionID, have ALTER SYSTEM privilege, or have DBA 
privileges. 



GET_SESS ION_TIMEOU 

T(sessionlD) 



This function returns the current timeout value of resumable 
space allocation for the session with sessionID. This returned 
timeout is in seconds. If the session does not exist, this function 
returns -1. 



SET_SESSI0M_TIMEOU 
T(sessionID, 
timeout ) 



This procedure sets the timeout interval of resum.able space 

allocation for the session with sessionID. The parameter 
timeout is in seconds. The new timeout setting will applies 
to the session immediately. If the session does not exist, no 
action is taken. 



GET TIMEOUT) 



This function returns the current timeout value of resumable 
space allocation for the current session. The returned value is in 

seconds. 
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Procedure 



Description 



SET_TIMEOUT ( timeou 
t) 



This procedure sets a timeout value for resuniable space 
allocation for the current session. The parameter timeout is in 
seconds. The new timeout setting applies to the session 
immediatelv 



See Also: Oracle Database PL/SQL Packages and Types Reference 



Operation-Suspended Alert 



When A resumable session is suspended, an operation-suspended alert is issued on the 
object that needs allocation of resource for the operation to complete. Once the 
resource is allocated and the operation completes, the operation- suspended alert is 
cleared. Please refer to "Managing Tablespace Alerts" on page 17-1 for more 
information on system-generated alerts. 



Resumable Space Allocation Example: Registering an AFTER SUSPEND Trigger 

In the following example, a system wide AFTER SUSPEHD trigger is created and 
registered as user SYS at the database level. Whenever a resumable statement is 
suspended in anv session, this trigger can have either of two effects: 

■ If an undo segment has reached its space limit, then a message is sent to the DBA 
and the statement is aborted. 

■ If any other recoverable error has occurred, the timeout interval is reset to 8 hours. 
Here are the statements for this example: 

CREaiE OR REPLaCE TRIGGER resuinable_de fault 

AFTER SDSPEND 

OH DATABASE 

DECLARE 

/* declare transaction in this trigger is autonomous '/ 

/*■ this is not required because transactions within a trigger 

are always autonomous */ 
PRAGMA AUT0H0M0US_TRMSACTION; 



cur_3id 
cur_ins t 
ermo 
err_type 
object_owner 
object_tYpe 
t ab 1 e_s pa c e_nanie 
object_naine 
sub_ob j e c t_naine 
error_txt 
msg_body 
ret_value 
mail_conn 
BEGIH 

-- Get session ID 
SELECT DISTINCTISID 



NUMBER; 

NUMBER; 

NUMBER; 

VARCHftR2 ; 

VARCHftR2 ; 

VARCHftR2 ; 

VARCHftR2 ; 

VARCHftR2 ; 

VARCHftR2 ; 

VARCHftR2 ; 

VARCHftR2 ; 

BOOLEM; 

UTL_SMTP.CONMECTIDH; 



INTO cur_SID FROM VSMYSTAT; 



-- Get instance number 
cur_inst := userenv [' instance ' ) 

-- Get space error information 
ret value := 
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DBMS_EESnMABLE.SPACE_EREOH_IHFO(err_type,ob]ect_type,object_owner, 

table_Epace_naine, object_riame, s"ub_ob j ec t_naiiie ) ; 
/•■ 

— If the error is related to undo segmentE, log error, send email 

-- to DBA, and abort the statsment. Otherwise, set timeout to 8 hours. 

— sya .rbs_error is a table which is to be 

— created by a DBA manually and defined as 

— (sql_text VAECHAR2(1000), error _msg VARCHftR2 (4000) , 

— suspend_time DATE) 
'/ 

IF OBJECT_TYPE = 'nHDO SEGMENT' THEN 
/* LOG ERROR */ 
IHSERT INTO sys .rbE_error ( 

SELECT SQL_TEXT, ERROR_HSG, SOSPEND_TIHE 
FROM DBMS_RESUMftBLE 

WHERE SES3I0H_ID = cur_Eid MD INSTMCE_ID = cur_inst 
); 

SELECT ERHOR_MSG INTO error_txt FROM DBMS_RESOMftBLE 

IfflERE SESSIOH_ID = cur_sid and INSTMCE_ID = cur_inst; 

-- Send email to receipisnt via UTL_SMTP package 
msg_body :=' Subject: Space Error Occurred 

Space limit reached for undo segment ' | | object_nanie 
on ' I I TO_CHAR(SYSDATE, 'Month dd, YYYY, HHrMIam' ) || 
' . Ebrror message was ' | | error_txt; 

maiLcorai := UTL_SHTP.OPEN_C0miECTI0N( ' localhost ' , 25); 
UTL_SMTP.HELO(mail_conn, 'localhost') ; 
UTL_SMTP.MAIL[mail_conn, ' sender Sloe a Ihos t ' ) ; 
UTL_SMTP.RCPT[iiiail_conn, 'recipientOlocalhost ' ) ; 
UTL_SMTP.DATA[iiiail_conn, msg_body) ; 
UTL_SMTP .QDIT [mail_conn) ; 

-- Abort the statement 

DBMS_RESUMABLE.flBORT(cur_sid) ; 
ELSE 

-- Set timeout to 8 hours 

DBMS_HESUMAELE.SET_TIMEOnT(28SO0) ; 
END IF; 

/* commit autonomous transaction '/ 
COMMIT; 

EHD; 
/ 
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This section explains how to reclaim wasted space, and also introduces the Segment 
Advisor, which is the Oracle Database component that identifies segments that have 
space available for reclamation. The following topics are covered; 

■ Understanding Reclaimable Unused Space 

■ Using the Segment Advisor 

■ ShrinkingDatabaseSegmentsOnline 

■ Deallocating Unused Space 
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Understanding Reclaimable Unused Space 

Over time, updates and deletes on objects within a tablespace can create pockets of 
empty space that individually are not large enough to be reused for new data. This 
type of empty space is referred to as fragmented free space. 

Objects with fragmented free space can result in much wasted space, and can impact 
database performance. The preferred way to defragment and reclaim this space is to 
perform an online segment shrink. This process consolidates fragmented free space 
below the high water mark and compacts the segment. After compaction, the high 
water mark is moved, resulting in new free space above the high water mark. That 
space above the high water mark is then deallocated. The segment remains available 
for queries and DML during most of the operation, and no extra disk space need be 
allocated. 

You use the Segment Advisor to identify segments that would benefit from online 
segment shrink. Onlv segments in locally managed tablespaces with automatic 
segment space management (ASSM) are eligible. Other restrictions on segment tvpe 
exist. For more information, see "Shrinking Database Segments Online" on page 17-28. 

If a table with reclaim.able space is not eligible for online segment shrink, or if you 
want to make changes to logical or physical attributes of the table while reclaiming 
space, you can use online table redefinition as an alternative to segment shrink. 
Online redefinition is also referred to as reorganization. Unlike online segment shrink, 
it requires extra disk space to be allocated. See "Redefining Tables Online" on 
page 18-26 for more information. 



Using tlie Segment Advisor 



The Segment Advisor identifies segments that have space available for reclamation. It 
performs its analysis by examining usage and growth statistics in the Automatic 
Workload Repository (AWR), and by sampling the data in the segment. It is 
configured to run during maintenance windows as an automated maintenance task, 
and you can also run it on demand (manually). The Segment Advisor automated 
maintenance task is known as the Automatic Segment Advisor 

The Segment Advisor generates the following types of advice: 

■ If the Segment Advisor determines that an object has a significant amount of free 
space, it recommends online segment shrink. If the object is a table that is not 
eligible for shrinking, as in the case of a table in a tablespace without automatic 
segment space management, the Segment Advisor recommends online table 
redefinition, 

■ If the Segment Advisor encounters a table with row chaining above a certain 
threshold, it records that fact that the table has an excess of chained rows. 



Note: The Segment Advisor flags only the tvpe of row chaining that 
results from updates that increase row length. 



If you receive a space management alert, or if you decide that you want to reclaim 
space, you should start with the Segment Advisor. 

To use the Segment Advisor 

1 . Check the results of the Automatic Segment Advisor 
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To understand the Automatic Segment Advisor, see "Automatic Segment 
Advisor", later in tliis section. For details on how to view results, see "Viewing 
Segment Advisor Results" on page 17-21, 

2. (Optional) Obtain updated results on individual segments by rerunning the 
Segment Advisor manuallv. 

See "Running the Segment Advisor Manually", later in this section, 

Automatic Segment Advisor 

The Automatic Segment Advisor is an automated maintenance task that is configured 
to run during all maintenance windows. 

The Automatic Segment Advisor does not analyze ever}' database object. Instead, it 
examines database statistics, samples segment data, and then selects the ioUowing 
objects to analyze: 

■ Tablespaces that have exceeded a critical or warning space threshold 

■ Segments that have the most activity 

■ Segments that have the highest growth rate 

If an object is selected for analysis but the maintenance window expires before the 
Segment Advisor can process the object, the object is included in the next Automatic 
Segment Advisor run. 

You cannot change the set of tablespaces and segments that the Automatic Segment 
Advisor selects for analvsis. You can, however, enable or disable the Automatic 
Segment Advisor task, change the times during which the Automatic Segment 
Advisor is scheduled to run, or adjust automated maintenance task system resource 
utilization. See "Configuring the Automatic Segment Advisor" on page 17-27 for more 
information. 

See Also: 

■ "Viewing Segment Advisor Results" on page 17-21 

■ Chapter 24, "Managing Automated Database Maintenance Tasks" 

Running the Segment Advisor Manualiy 

You can manually run the Segment Advisor at anv time with Enterprise Manager or 
with PL /SQL package procedure calls. Reasons to manually run the Segment Advisor 
include the following: 

■ You want to analyze a tablespace or segment that was not selected by the 
Automatic Segment Advisor. 

■ You want to repeat the analvsis of an individual tablespace or segment to get more 
up-to-date recommendations. 

You can request advice from the Segment Advisor at three levels: 

■ Segment level — Advice is generated for a single segment, such as an 
unpnrtitioned table, a partition or subpartition of a partitioned table, an index, or a 
LOB column. 

■ Object level — Advice is generated for an entire object, such as a table or index. If 
the object is partitioned, advice is generated on all the partitions of the object. In 
addition, if vou run Segment Advisor manuallv from Enterprise Manager, vou can 
request advice on the object's dependent objects, such as indexes and LOB 
segments for a table. 
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■ Tablespace level — Advice is generated for every segment in a tablespace. 

TheOBJECT_TYPE column of Table 17-3 on page 17-20 shovifs the types of objects for 
which you can request advice. 

Running the Segment Advisor Manually with Enterprise Manager You must have the 
OEM_ADVISOR role to run theSegment Advisor manually with Enterprise Manager 
There are two wavs to run the Segment Advisor; 

■ Using the Segment Advisor Wizard 

This method enables vou to request advice at the tablespace level or object level. 
At the object level, vou can request advice on tables, indexes, table partitions, and 
index partitions. Dependent objects such as LOB segments cannot be included in 
the analysis. 

■ Using the Run Segment Advisor command on a schema object page. 

For exan\ple, if you displav a list of tables on the Tables page (accessible from the 
Schema page), you can select a table and tlien select the Run Segment Advisor 
command from the Actions menu. 



Figure 17-1 Tablespage 
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This method enables you to include the schema object's dependent objects in the 
Segment Advisor run. For example, if vou select a table and select the Run 
Segment Advisor command. Enterprise Manager displavs the table's dependent 
objects, such as partitions, index segments, LOB segments, and so on. You can 
then select dependent objects to include in the run. 

In both cases. Enterprise Manager creates the Segment Advisor task as an Oracle 
Database Scheduler job. You can schedule the job to run immediately, or can take 
advantage of advanced scheduling features offered by the Scheduler 

To run the Segment Advisor manually with the Segm.ent Advisor Wizard; 

1. From the database Home page, under Related Links, click Advisor Central, 
The Advisor Central page appears. (See Figure 17-2.) 
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2. Under Advisors, click Segment Advisor. 

Tlie first page of the Segment Advisor wizard appears, 

3. Follow the wizard steps to schedule the Segment Advisor job, and then click 
Submit on the final wizard page. 

The Advisor Central page reappears, with the new Segment Advisor job at the top 
of the list under the Results heading. The job status is SCHEDULED or RUNNING, (If 
you do not see vour job, use the search fields above the list to display it,} 

4. Check the status of the job. If it is not COMPLETED, click the Refresh button at the 
top of the page repeatedlv, (Do not use your browser's Refresh icon,) 

When the job status changes to COMPLETED, select the job by clicking in the Select 
column, and then click View Result, 

Figure 17-2 Advisor Central page 
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See Also: Chapter 27, "Scheduling Jobs with Oracle Scheduler" for 
more information about the advanced scheduling features of the 
Scheduler 

Running the Segment Advisor Manually with PL/SQL You can also run the Segment Advisor 
with the DBMS_ADVISOR package. You use package procedures to create a Segment 
Advisor task, set task arguments, and then execute the task. You must have the 
ADVISOR privilege. Table 17—2 shows the procedures that are relevant for the Segment 
Advisor. Please refer to Orach Database PL/SQL Packages and T^jpes Reference for more 
details on these procedures. 
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Table 1 7-2 DBMS_ADVISOR package procedures relevant to the Segment A dvisor 
Package Procedure Name Description 



CREATE TASK 



CREATE OBJECT 



Use this procedure to create the Segment Advisor task. Specify 'Segment Advisor' 
as the value of the ADVISOR_NAME parameter. 

Use this procedure to identify the target object for segment space advice. The 
parameter vakies of this procedure depend upon the object type. Table 17-3 hsts 
the parameter values for each type of object. 

Note: To request advice on an lOT overflow segment, use an object type of TABLE, 
TABLE PARTITIOH, or TABLE SUBPARTITION. Use the following query to find 
the overflow segment for an lOT and to determine the overflow segment table 
name to use with CREATE_OBJECT: 

select table_nanie, iot_na]Le, iot_type from dba_tables; 

SET_TASK_PARAMETER Use this procedure to describe the segment advice that you need. Table 17-4 shows 

the relevant input parameters of this procedure. Param.eters not listed here are not 
used by the Segm.ent Advisor 



EXECUTE_TASK 


Use this procedure to execu' 


te the Segment Advisor task. 






Table 17-3 Input for DBMS_ADVISOR.CREATE_OBJECT 


Input Parameter 


OBJECT_TYPE 


ATTR1 ATTR2 


ATTR3 


ATTR4 




TABLES PACE 


tshlespace NULL 
name 


NULL 


Unused. 


Specify NULL. 


TABLE 


schema, name table name 


NULL 


Unused. 


Specify NULL. 


INDEX 


schema name index name 


NULL 


Unused. 


Specify NULL. 


TABLE PARTITION 


schema name table name 


table partition name 


Unused. 


Specify NULL. 


INDEX PARTITION 


schema name index name 


index partition name 


Unused. 


Specify NULL. 


TABLE 
SUBPARTITION 


schema name table name 


table subpartition 
name 


Unused. 


Specify NULL. 


INDEX 
SUBPARTITION 


schema name index name 


index subpartition 
name 


Unused. 


Specify NULL. 


LOB 


schema name segment name 


NULL 


Unused. 


Specify NULL. 


LOB PARTITION 


schema name segment name 


lob partition name 


Unused. 


Specify NULL. 


LOB SUBPARTITION 


schema name segment name 


lob subpartition name 


Unused. 


Specify NULL. 


Table 17-4 Input for DBMS_ADVISOR.SET_TASK_RARAML 1 LR 


Input Parameter Description Possible Values 


Default Value 



time_lirait The time limit for the Segment Anv number of seconds 

Advisor run, specified in 

seconds. 



UNLIMITED 



recommend_all Whether the Segment Advisor TRUE: Findings are generated on all TRUE 

should generate findings for all segments specified, whether or not space 
segments. reclamation is recommended. 

FALSE: Findings are generated only for 
those objects that generate 
recommendations for space reclamation. 
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Example The example that follows shows how to use the DBMS_ADVI SOR 
procedures to run the Segment Advisor for the sample table hr . employees. The user 
executing these package procedures must have the EXECUTE object privUege on the 
package or the ADVI SOR system privilege. 

Note that passing an object t>'pe of TABLE to DBMS_ADVISOR. CREATE_OBJECT 
amounts to nn object level request. If the table is not partitioned, the table segment is 
analvzed (without anv dependent segments like index or LOB segments). If the table is 
partitioned., the Segment Advisor analyzes all table partitions and generates separate 
findings and recommendations for each. 

variable id number; 
begin 

declare 

name vaxchar2 (100) ; 

deacr varchar2 {500} ; 

obj_id number; 

begin 

nai[ie:= ' Manna l_Employees ' ; 

descr:= 'Segment Advisor Example'; 

dbin3_advisor . create_task { 

advisor_name => 'Segment Advisor', 

taEk_id => :id, 

taEk_naiiie => name, 

task_desc => descr) ; 

dbm3_advisor . create_object [ 



task name 


=> name. 


object. 


-type 


=> • TABLE ' , 


attrl 




=> ' HR ' , 


attr2 




=> 'EMPLOYEES 


attrS 




=> HULL. 


attr4 




=> HULL. 


attrB 




=> HULL, 


ob j ec t_ 


_id 


= > obj_id) ; 



dbms_advisor .Eet_task_parameter [ 
taEk_name => name, 

parameter => 'recommend_all ' 

value => 'TRUE') ; 

dbm3_advisor .execute_taEk{name) ; 
end; 



Viewing Segment Advisor Resuits 

The Segment Advisor creates several t\'pes of results: recommendations, findings, 
actions, and objects. You can view results in the following w^ays: 

■ With Enterprise Manager 

■ By querying the DBA_ADVI30R_* views 

■ By calling the DBMS_SPACE . ASA_RECOMMENDATIOWS procedure 
Table Table 17— E> describes the various result types and their associated 

DBA ADVISOR * views. 
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Table 1 7-5 Segment A dvisor Result Types 



ResuK Type 



Associated View 



Recommendations DBA ADVISOR RE COMMEND AT I OHS 



Findings 



DBA ADVISOR FINDIHGS 



Actions 



DBA ADVISOR ACTIONS 



Objects 



DBA ADVISOR OBJECTS 



Description 



If a segment would benefit from a segment shrink or 
reorganization, the Segment Advisor generates a 
recommendation for the segment. Table 17-6 shows 
examples of generated findings and 
recommendations. 

Findings are a report of what the Segment Advisor 
observed in analyzed segments. Findings inchide 
space used and free space statistics for each analyzed 
segment. Not all findings result in a 
recommendation. [There mav be only a few 
recommendations, but there could be many findings.) 
When running the Segment Advisor manually with 
PL/SQL, if you specify 'TRUE' for recommend_all 
in the SET_TASK_PARAMETER procedure, then the 
Segment Advisor generates a finding for each 
segment that qualifies for analysis, whether or not a 
recommendation is made for that segment. For row 
chaining advice, the Automatic Segment Advisor 
generates findings onlv, and not recommendations. If 
the Automatic Segment Advisor has no space 
reclamation recommendations to make, it does not 
generate findings. 

Every recommendation is associated with a 
suggested action to perform: either segment shrink or 
online redefinition (reorganization). The 
DBA_ADVISOR_ACTIOHS view provides either the 
SQL that you need to perform a segment shrink, or a 
suggestion to reorganize the object. 

All findings, recommendations, and actions are 
associated with an object If the Segment Advisor 
analyzes more than one segment, as with a tablespace 
or partitioned table, then one entry is created in the 
DBA_ADVISOR_OBJECTS view for each analyzed 
segment. Table 17-3 defines the columns in this view 
to query for information on the analyzed segments. 
You can correlate the objects in this view with the 
objects in the findings, recommendations, and actions 
views 



See Also: 

■ Oracle Database Reference for details on the DBA_ADVI SOR_* 
vievifs. 

■ Oracle Database PL/SQL Packages and Types Reference for details on 

the DBMS_SPACE . ASA_RECOMMENDATIONS function. 

Viewing Segment Advisor Results witii Enterprise IVIanager 

With Enterprise Manager (EM), vou can view Segment Advisor results for both 
Autoniiitic Segment Advisor runs and manual Segment Advisor runs. You can view 
the following types of results: 

■ All recommendations (multiple automatic and manual Segment Advisor runs) 

■ Recommendations from the last Automatic Segment Advisor run 

■ Recommendations from a specific run 
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■ Row chaining findings 

YoLL can also view a list of the segments that were analyzed bv the last Automatic 
Segment Advisor run. 

To view Segment Advisor results with EM — All runs: 

1. On the database Home page, under the Space Summar}' heading, click the 
numeric link next to the title Segment Advisor Recommendations. 



Space Sum mary 

Database Size (6B) 
Problem Tables paces ^ 
Segment Advisor RecommendatitJns ^ 
Policy Violation ^ TK 
Dump Area Used (%) 



Z.BD7 
Z 



The Segment Advisor Recommendations page appears. Recommendations are 
organized by tablespace. 

Figure 17-3 Segment Advisor Recommendations page 



Database Instancp: database 



'ions 



Oracle u^e^ the Automatic Segment Advisor lob to detect segment i^^ues regularly within maintenance windows. The f cdldwing table contains the 
minimum reclaimable space summary for the evaluated segments in that tablespace. The recommendations come from the most recent runs of 
automatic and user-scheduled segment advisor jobs, and are based on the growth trend of the segment. Oracle recommends shrinking or reorganizing 
these segments to release unused space. Select the Recommendation Details button to view and implement the recommendations. 



View 1 All Recommendations 


^1 










[ Recommenclalion Details 1 I 


setect 


Tablespace 


QecommendatiDns 


Tablespace 
Si;e (MB) 


Evaluated 
Space (*^^) Qedalmable Space (MB) ^ 


EKtent 
Management 


Segment Space 
Management 


© 


TVMDS ASSM 


4 


500.00, 87.41 


433.98 LOCAL 


AUTO 


O 


TVMDS MSSM NEVrf 


Z 


500,00 


86.54 


431.00 LOCAL 


MANUAL 


o 


TVHDS ASSH NEW 


3 


500,00 


56.53 


281.20 LOCAL 


AUTO 



RalatEd Links 



Advispr Central 

Run SBumgnt Advisor Manually 

Job Scheduler 



Automated Maintenance Tasks 
Chained Row Analysis 



2. If any recommendations are present, select a tablespace, and then click 
Recommendation Details. 

The Recommendation Details page appears. You can initiate the recommended 
activity from this page (shrink or reorganize). 
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Figure 17-4 Recommendation Details page 

Database Instance: database > Segment Advisor Recommendations > 
Recommendation Details for Ti)lespace: TVMDS_ASSM_^EW__ 
View fiW Recammendatlons 



Oracle u^e^ the Automatic Segment Advi^oi job to detect segment i^^ue^ lequlaily vithin rreintenance windows. The Following taHe contan^ the reclaim^ble 
5pace inFormatiori For fhe evaluafed wgnlenlsin Che^electeil tablegiace, The lecorTiiTiendctions ccme fiom Che miKt recent runsaf autorratn: and 
L|5er-scheduled segment advfiC" lobs, and are based on the growth fend cf the segment. Oracle recommends shrnljng or reorganizing these segments to 
release unused space. Select the segment ta impleiTent the recommendation. 
^':lienia Segment Parlition Minimum Peclaimable Spac e (ME) 



Search , 



[ ImplemenI ) 


::elec: All | Select Nme 


Select 


Schema 


^^^^^^^^B 


Recommendatran 


Recldlmable Space (MB) n 


f^DDcated Space Used Space Segment 
(MB) (MB) Type 










I—I jSYS TVMD5_5H1INK_TABLE_PEW 


( Shrink ) 


148. ?0 


149.00 


0.80 


TABLE 






98,00 


98.00 


0,00 


INDEX 


U 


5V5 TVMD5_SHPlNK_rEW_INDEX 


ISIinriKl 


□ 


1 




35,00 


35.00 


0,00 


INDEK 


ST5 


TVMDS_5HllNKJEWJNPEX_AUrO 


(Slirmk) 



Tip: The list entries are sorted in descending order by reclaimable 
space. You can click column headings to change the sort order or to 
change from ascending to descending order. 



To view Segment Advisor results with EM — Last Automatic Segment Advisor run: 

1. On the database Home page, under the Space Sumniar\" heading, click the 
numeric link next to the title Segment Advisor Recommendations, 

The Segment Advisor Recommendations page appears. (See Figure 17-3.) 

2. In the View drop-down list, select Recommendations from Last Automatic Run. 

3. If anv recommendations are present, click in the Select column to select a 
tablespace, and then click Recommendation Details. 

The Recommendation Details page appears. (See Figure 17-4, } You can initiate the 
recommended activit}' from this page (shrink or reorganize). 



To view^ Segment Advisor results w^ith EM — Specific run; 

1. Start at the Advisor Central page. 

If vou ran the Segment Advisor with the Enterprise Manager wizard, the Advisor 
Central page appears after you submit the Segment Advisor task. Otherwise, to 
get to this page, on the database Home page, under Related Links, click Advisor 
Central. 

2. Check that vour task appears in the list under the Results heading. If it does not, 
complete these steps (See Figure 17-2 on page 17-19): 

a. In the Search section of the page, under Advisor Tasks, select Segment 
Advisor in the Advisory Type list. 

b. In the Advisor Runs iist, select All or the desired time period. 

c. (Optional) Enter a task name, 

d. Chck Go. 

Your Segment Advisor task appears in the Results section. 
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3. Check the status of the job. If it is not COMPLETED, dick the Refresh button at the 
top of the page until your task status shows COMPLETED. (Do not use your 
browser's refresh icon.) 

4. Click the task name. 

The Segment Advisor Task page appears, with recommendations organized by 
table space. 

5. Select a tablespace in the list, and then click Recommendation Details, 

The Recommendation Details page appears. (See Figure 17— 1.) You can initiate the 
recommended activit}' from this page (shrink or reorganize). 



To view row^ chaining findings 

1 . On the database Home page, under the Space Summary heading, click the 
numeric link next to the title Segment Advisor Recommendations. 

The Segment Advisor Recommendations page appears. (See Figure 17-3.) 

2. Under the Related Links heading, click Chained Row Analysis. 

The Chained Row Analysis page appears, showing all segm.enls that have chained 
rows, with a chained rows percentage for each. 

Viewing Segment Advisor Results by Querying the DBA_ADVI50R_* Views 

The headings of Table 17-6 show the columns in the DBA_ADVI30R_* views that 
contain output from the Segment Advisor. Refer to Oracle Database Reference for a 
description of these views. The table contents summarize the possible outcomes. In 
addition. Table 17-3 on page 17-20 defines the columns in the 
DBA_ADVISOR_OBJECTS view that contain information on the analyzed segments. 

Before querying the DBA_ADVISOR_' views, you can check that the Segment Advisor 
task is complete by querying the STATUS column in DBA_ADVI SOR_TASKS, 

select ta3k_nanie, status from iiba_advisor_taEks 

where owner = 'STEVE' and advisor_nanie = 'Segment Advisor'; 

TASKJJAHE STATUS 

Manual Employees COHPLETEaj 



The following example shows how to query the DBA_ADVISOR_* views to retrieve 
findings from all Segment Advisor runs submitted bv user STEVE: 

select af .task_naiiLe, ao,attr2 segname, ao.attrS partition, ao,type, af. message 
from dba_advisor_f indings af, dba_advisor_ob]ects ao 
where ao.task_id = af , task_id 
and ao,object_id = af,object_id 
and ao, owner = 'STEVE'; 



TASKJAHE SEGNAME PARTITION TYPE MESSAGE 

Manual_Eiiiployees EMPLOYEES TABLE The free space in the obje 

ct is less than lOHB. 

Manual_Salestalile4 SALESTABLE4 SALES TABLE4_P1 TABLE PARTITIOH Perform shrink, estimated 

savings is 74444154 bytes. 
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Manual Salestable4 SALESTABLE4 SALE3TABLE4 P2 TABLE PARTITIOl 



The free space in the obje 
ct is less than 10MB. 



Table 1 7-6 Segment A dvisor Outcomes: Summary 



MESSAGE column of 
DBA_ADVISOR_FINDINGS 


MORE INFO column of 
DBA_ADVISOR_FINDINGS 


BENEFIT TYPE 
DBA ADVISOR 
DATIONS 


column of 
_RECOMMEN 


ATTRI column of 
DBA_ADVISOR_ACTIONS 


Insufficient information to 

make <i recommend a ti on. 


None 


None 








None 


The free splice in the object 

is less than 10MB. 


Allocated Spaceiiii; Used 
Space; hi; Reclaimable 
Space \xxx 


None 








None 


The object has some free 
space but cannot be shrunk 
because... 


Allocated Space;iii; Used 
Space;iii; Reclaimable 
Space \xxx 


None 








None 


The free space in the object 
is less than the size of the 
last extent. 


Allocated Space;.i:.i:.T:; Used 
Space; hi; Reclaimable 
Space ;iii 


None 








None 


Perform shrink, estimated 
savings is xxx bvtes. 


Allocated Space;iii; Used 
Space; hi; Reclaimable 
Space ;iii 


Perform shrink, i 
savings is iii by 


estimated 
tes. 


The command to execute. 
For example; ALTER 

oijecfc SHRINE SPACE;) 



Enable row movement of 

the table schetim.fuhle and 
perform shrink, estimated 
savings is xxx bvtes. 

Perform re-org on the object 
object, estimated savings is 
HI bvtes. 

(Note: This finding is for 
objects with reclaimable 
space that are not eligible 
for online segment shrink.) 



Allocated Space;iii; Used 
Space; hi; Reclaimable 
Space ;iii 



Allocated Space;j:ii; Used 
Space; hi; Reclaimable 
Space ;iH 



Enable row movement of the 

table schetim.fuhle and perform 
shrink, estimated savings is 
HI bvtes 



The command to execute. 
For example; ALTER 

ohject SHHItJE SPACE;) 



Perform re-org on the object 
object, estimated savings is hi 
bytes. 



Perform reorg 



The object has chained rows xx percent chained row scan None 

that can be rem.oved by be removed bv re-org. 

re-org. 



None 



Viewing Segment Advisor Results with DBM5_SPACE.ASA_REC0MMENDATI0NS 

The ASA_RECOMMEWDAT IONS procedure in theDBMS_SPACE package returns a nested 
table object that contains findings or recommendations for Automatic Segment 
Advisor runs and, optionally, manual Segment Advisor runs. Calling this procedure 
may be easier than working with the DBA_ADVI SOR_'^ views, because the procedure 
performs all the required joins for you and returns information in an easily 
consumable format. 

The following querv returns recommendations by the most recent run of the Auto 
Segment Advisor, with the suggested command to run to follow the 
recommendations: 

select tablespace_iiame, segmerit_riaine, seginent_type, partition_name, 

recommendations, cl from 

table {dbms_space.aEa_recoramendations( 'FALSE', 'FALSE' , 'FALSE' }) ; 



TABLES PACE_HME 
PARTITIOH HME 



SEGMENT MAME 



SEGMENT TYPE 
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RECOMMENDATIOHS 
CI 



TUMDS_A5SM OHDESSl TABLE PARTITION 

ORDERS 1_P2 

Perforni shrink, estimated savings is 57566422 bytes. 

alter table "STEVE" . "ORDERSl" modify partition "0RDERS1_P2" shrink space 

TUMDS_ASSM ORDERSl TABLE PARTITIOH 

ORDERS 1_P1 

Perforni shrink, estimated savings is 45083514 bytes. 

alter table "STEVE" . "ORDERSl" modify partition "0RDERS1_P1" shrink space 

TVMDS_ASSM_NEW ORDERS_NEH TABLE 

Perforni shrink, estimated savings is 155398992 bytes, 
alter table "STEVE" . "ORDERSJEW" shrink space 

TVMDS_ASSM_NEM ORDERS_HE'/i_INDEX UTOEX 

Perforni shrink, estimated savings is 102759445 bytes, 
alter index "STEVE" . "ORDERS_MEW_INDEX" shrink space 

See Oracle Database PL/SQL Packages and Types Reference for details on 

DBMS_SPACE.ASA_REC;OMMENDATIOWS. 

Configuring the Automatic Segment Advisor 

The Automatic Segment Advisor is an automated maintenance task. As such, you can 
use Enterprise Manager or PL/SQL package procedure calls to modify when (and if) 
this task runs. You can also control the resources allotted to it by modifying the 
appropriate resource plans. 

You can call PL /SQL package procedures to make these changes, but the easier way to 
is to use Enterprise Manager. 

To configure the Autom.atic Segment Advisor task *vith Enterprise Manager: 

1. Log in to Enterprise Manager as user SYSTEM. 

2. On the Database Home page, under the Space Summary heading, click the 
numeric link next to the label Segment Advisor Recommendations. 



Sgace Summary 

Database Size (GB) Z.BD? 

Problem Tables pace ^ ^ 2 

Segment Advisor" Recommeridebon^ ^ 9 ^— 

Policy Violebon^ SV 1 
Dump AreaU?ed (%) ''_2 



The Segment Advisor Recommendations page appears. 

3. Under the Related Links heading, click the link entitled Automated Maintenance 

Tasks. 

The Automated Maintenance Tasks page appears. 

4. Chck Configure. 

The Automated Maintenance Tasks Configuration page appears. 
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Database Instance: database > Automated Maintenance Tasks > 



Autom ated Maintenance Tasks ConfiquraUon 



Logged in As SYSTEM 
( Show SQL ) ( Revert ) ( Apply ) 



Global status ©Enabled O Disabled 
Task Settings 



Optimizer statistics Gathering ©Enabled Opisabled t Configure ] 
Segment Advisor © Enabled O Disabled 



Automatic SQL Tuning ©Enabled Opisabledl Configure . 



Maintenance Window Group Assignment 



»M9B. 



.VEDNESDAV WINDDW 



THURSDAV WINDOW 



=RIDAV WINDOW 



SATURDAV WINDOW 



SUNDAY WINDOW 



YIQNDAY WINDOW 



TUESDAY WINDOW 



t Eclil Window Group 
^r Statistics Gathering Segment Advisor Automatic SQL Tunlr^ 

Select All I Select None Select All I Select None Select All I Select Non_e 

_ 









5. To completely disable the Automatic Segment Advisor, under Task Settings, select 
Disabled next to the Segment Advisor label, and then click Apply. 

6. To disable the Automatic Segment Advisor for specific maintenance windows, 
clear the desired check boxes under the Segment Advisor column, and then click 
Apply, 

7. To modify the start and end times and durations of maintenance windows, click 
Edit Window Group. 

The Edit Window Group page appears. Click the name of a maintenance window, 
and then click Edit to change the window's scliedule. 

See Also: 

■ Chapter 24, "Managing Automated Database Maintenance Tasks" 

Viewing Automatic Segment Advisor Information 

The follow^ing views display information specific to the Automatic Segment Advisor. 
For details, see Oracle Database Reference. 



View 


Description 


DBA_AUTO_SEGADV_SUMMARY 


Eiich row of this view sumniiirizes one Automatic 
Segment Advisor run. Fields include number of 
t.^blespaces ^nd segments processed, and number of 
recommendations made. 


DBA_AOTO_SEGflriV_CTL 


Contains control information that the Automatic 
Segment Advisor uses to select and process segments. 
Each row contains information on a single object 
(tablespace or segment), including whether the object 
has been processed, and if so, the task ID under which 
it was processed and the reason for selecting it 



Shrinking Database Segments Online 



You use online segment shrink to reclaim fragmented free space below the high water 
mark in an Oracle Database segment. The benefits of segment sluink are tliese: 
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■ Com paction of data leads to better cache utilization, wliich in turn leads to better 
online transaction processing (OLTP) performance. 

■ The compacted data requires fewer blocks to be scanned in full table scans, which 
in turns leads to better decision support svstem (DSS) performance. 

Segment shrink is an online, in-place operation. DML operations and queries can be 
issued during the data movement phase of segment shrink. Concurrent DML 
operation are blocked for a short time at the end of the shrink operation, when the 
space is deallocated. Indexes are maintained during the shrink operation and remain 
usable after the operation is complete. Segment shrink does not require extra disk 
space to be allocated. 

Segment shrink reclaims unused space both above and below the high water mark. In 
contrast, space deallocation reclaims unused space onlv above the high water mark. In 
shrink operations, bv default, the database compacts the segment, adjusts the high 
water mark, and releases the reclaimed space. 

Segment shrink requires that rows be moved to new locations. Therefore, you must 
first enable row movement in the object you want to shrink and disable any 
rowid-based triggers defined on the object. You enable row movement in a table with 

the ALTER TABLE ,,, ENABLE ROW MOVEMENT command. 

Shrink operations can be performed only on segments in locallv managed tablespaces 
with automatic segment space management (ASSM), Within an ASSM tablespace, all 
segment types are eligible for online segment shrink except these: 

■ lOT mapping tables 

■ Tables with rowid based materialized views 

■ Tables with function-based indexes 

■ SECUREFILE LOBs 

See Also: Oracle Database SQL Language Reference for naore 
information on the ALTER TABLE command. 

Invoking Online Segment Shrink 

Before invoking online segment shrink, view the findings and recommendations of the 
Segment Advisor For more information, see "Using the Segment Advisor" on 
page 17-16. 

You invoke online segment shrink with Enterprise Manager (EM) or with SQL 
commands in SQL'PIus, The remainder of this section discusses the command line 
method. 



Note: You can invoke segment shrink directlv from the 
Recommendation Details page in EM, (See Figure 17—4,) Or, to invoke 
segment shrink for an individual table in EM, display the table on the 
Tables page, select the table, and then click Shrink Segment in the 
Actions hst (See Figure 17-1,) Perform a similar operation in EM to 
shrink indexes, materialized views, and so on. 



You can shrink space in a table, index- organized table, index, partition, subpartition, 
materialized view, or materialized view log. You do this using ALTER TABLE, ALTER 

INDEX, ALTER MATERIALIZED VIEW, or ALTER MATERIALIZED VIEW LOG statement 

with the SHRINK SPACE clause. Refer to Oracle Database SQL Language Reference for 
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the svntax and additional information on shrinking a database object, including 
restrictions. 

Two optional clauses let you control how the shrink operation proceeds: 

■ The COMPACT clause lets you divide the shrink segment operation into two phases. 
When you specify COMPACT, Oracle Database defragments the segment space and 
compacts the table rows but postpones the resetting of the high water mark and 
the deallocation of the space until a future time. This option is useful if vou have 
long-running queries that might span the operation and attempt to read from 
blocks that have been reclaimed. The defragmentation and compaction results are 
saved to disk, so the data movement does not have to be redone during the second 
phase. You can reissue the SHRINK SPACE clause without the COMPACT clause 
during off-peak hours to complete the second phase, 

■ The CASCADE clause extends the segment shrink operation to all dependent 
segments of the object. For example, if vou specify CASCADE when shrinking a 
table segment, all indexes of the table will also be shrunk. (You need not specify 
CASCADE to shrink the partitions of a partitioned table.) To see a list of dependent 
segments of a given object, you can run the OBJECT_DEPEWDEWT_SEGMEWTS 
procedure of the DBMS_gPACE package. 

As with other DDL operations, segment shrink causes subsequent SQL statements to 
be reparsed because of invalidation of cursors unless you specify the COMPACT clause. 

Examples 

Shrink a table and all of its dependent segments (including BASICFILE LOB 
segments): 

ALTER TABLE employees SHRINK SPACE CASCADE; 

Shrink a BASICFILE LOB segment only: 

ALTER TABLE employees MODIFY LOB (perf_review) (SHRIHK SPACE) ; 

Shrink a single partition of a partitioned table: 

ALTER TABLE customers MODIFY PARTITION cust_Pl SHRINK SPACE; 

Shrink an lOT index segment and the overflow segment: 

ALTER TABLE cities SHRIHK SPACE CASCADE; 

Shrink an lOT overflow segment only: 

ALTER TABLE cities OVERFLOW SHRINK SPACE; 

See Also: Oracle Database SecureFiles and Large Objects Developer's 
Guide for more information about LOB segments 



Deallocating Unused Space 



When you deallocate unused space, the database frees the unused space at the unused 
(high water mark) end of the database segment and makes the space available for 
other segments in the tablespace. 

Prior to deallocation, you can run the UNUSED_SPACE procedure of the DBMS_SPACE 
package, which returns information about the position of the high water mark and the 
amount of unused space in a segment. For segments in locally managed tablespaces 
with automatic segment space management, use the SPACE_USAGE procedure for 
more accurate information on unused space. 
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See Also: Oracle Database PL/SQL Packages and Types Reference 
coiitams the description of the DBMS_SPACE package 

The following statements deallocate unused space in a segment (table, index or 
cluster): 

ALTER TABLE table DEALLOCATE UMUSED KEEP integer; 
ALTER INDEX index DEALLOCATE UNUSED KEEP integer; 
ALTER CLUSTER cluster DEALLOCATE UNUSED KEEP integer; 

The KEEP clause is optional and lets vou specify the amount of space retained in the 
segment. You can verify that the deallocated space is freed by examining the 

DBA_FREE_SPACE view. 

See Also: 

■ Oracle Database SQL Language Reference for details on the syntax 
and semantics of deallocating unused space 

■ Oracle Database Reference for more information about the 

DBA_FREE_SPACE view 

Understanding Space Usage of Datatypes 

When creating tables and other data structures, you need to know how much space 
they will require. Each datat\'pe has different space requirements. The Oracle Database 
PL/SQL Language Reference and Oracle Database SQL Language Reference contain 
extensive descriptions of datatypes and their space requirements. 

Displaying Information About Space Usage for Scliema Objects 

Oracle Database provides data dictionarv views and PL/SQL packages that allov^f you 
to display information about the space usage of schema objects. Views and packages 
that are unique to a particular schema object are described in the chapter of this book 
associated with that object. This section describes views and packages that are generic 
in nature and applv to multiple schema objects. 

Using PL/SQL Packages to Display Information About Schema Object Space Usage 

These Oracle- sup plied PL/SQL packages provide information about schema objects: 

Package and Procedure/ Function Description i 

DBMS_SPACE.UNDSED_SPACE Returns information about unused space in an 

object (table, index, or cluster). 



DBHS_SPACE.FREE_BLOCKS Returns information about free data blocks in an 

object (table, index, or cluster) whose segment free 
space is managed by free lists (segment space 
management is MAMUAL). 



DBMS_SPACE.SPACE_USAGE Returns information about free data blocks in an 

object (table, index, or cluster) whose segment space 
management is AUTO. 



See Also: Oracle Database PL/SQL Packages and Types Reference for 
a description of PL/SQL packages 
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Example: Using DBMS_SPACE.UNUSED_SPACE 

The following SQL'Plus example uses the DBMS_SPACE package to obtain unused 
space information, 

SQL> VARIABI£ totaLblocks NUMBER 

SQL> VARIABI£ total_bytes NUMBER 

SQL> VARIABLE ijnused_b locks NUMBER 

SQL> VARIABLE unused.bytes NUMBER 

SQL> VARIABLE lastextf NUMBER 

SQL> VARIABLE last_extb NUMBER 

SQL> VARIABLE lastusedblock NUMBER 

SQL> exec DBM3_SPACE.UHU3ED_3PACE (' SCOTT ' , 'EHP', 'TABLE', :total_blocks, - 

> : total_bytes, :imused_blocks, :"unused_bytes. :lastextf, - 

> :last_extb, : lastusedblock) ; 

PL/SQL procedure successfully completed. 
SQL> PRINT 
TOTAL_BLOCKS 
5 
TOTAL_BYTES 
10240 



LASTUSEDBLOCK 
3 

Schema Objects Space Usage Data Dictionary Views 

These views display information about space usage in schema objects: 



View Description 



DBA_SEGMEHTS DBA view describes storage allocated for all database segments. 

-.-___ _,„rmi-.iTmr- User view describes storaee allocated for segments for the 

~ current user. 



DBA_EXTEfJTS DBA view describes extents comprising all segments in the 

database. User view describes extents comprising segments for 
the current user 



USER EXTENTS 



DBA_FREE_SPACE DBA view lists free extents in all tablespaces User view shows 

T?RFT? tjparT? ^^^ space information for tablespaces for which the user has 

I ~ ~ quota. I 

The following sections contain examples of using some of these views. 

See Also: Oracle Database Referenee for a complete description of 
data dictionary views 

Example 1 : Displaying Segment Information 

The foilov/ing querv returns the name and size of each index segment in schema hr: 

SELECT SEGMENT_NAME, TABLESPACE_HAME, BYTES, BLOCKS, EXTENTS 
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FROM DBA_3EGMEHTS 

WHERE SEGMENT_T¥PE = 'IHDEX' 

AND 01NER='HR' 

ORDES BY 3EGMENT_HAME; 



The query output is: 

SEGMENT NAME 



TABLES PACE HAME 



BYTES BLOCKS EXTENTS 



COUNTRY_C_ID_PK 


EXAMPLE 


65536 


32 


1 


DEPT_ID_PK 


EXAMPLE 


65536 


32 


1 


DEPT_LOCATION_IX 


EXAMPLE 


65536 


32 


1 


EMP_DEPAETMENT_IX 


EXAMPLE 


65536 


32 


1 


EMP_EMAIL_UK 


EXAMPLE 


65536 


32 


1 


EMP_EMP_ID_PK 


EXAMPLE 


65536 


32 


1 


EMP_JOB_IZ 


EXAMPLE 


65536 


32 


1 


EMP_MANAGER_IZ 


EXAMPLE 


65536 


32 


1 


EMP_NAME_IX 


EXAMPLE 


65536 


32 


1 


JHIST_DEPARTMENT_IX 


EXAMPLE 


65536 


32 


1 


JHIST_EMPLOYEE_IX 


EXAMPLE 


65536 


32 


1 


JHIST_EMP_ID_3T_DATE_PK 


EXAMPLE 


65536 


32 


1 


JHIST_JOB_IX 


EXAMPLE 


65536 


32 


1 


JOB_ID_PK 


EXAMPLE 


65536 


32 


1 


LOC_CITY_IX 


EXAMPLE 


65536 


32 


1 


LOC_COUHTRY_IZ 


EXAMPLE 


65536 


32 


1 


LOC_ID_PK 


EXAMPLE 


65536 


32 


1 


LOC_STATE_PROVINCE_IX 


EXAMPLE 


65536 


32 


1 


EEG_ID_PK 


EXAMPLE 


65536 


32 


1 



19 rows selected. 

Example 2: Displaying Extent Information 

Information about the currently allocated extents in a database is stored in the 
DBA_EXTENTS data dictionarv view. For example, the following querv identifies the 
extents allocated to each index segment in the hr schema and the size of each of those 
extents: 

SELECT SEGMENT_NAME, SEGMENT_TYPE , TABLES PACE_NAME, EXTENT_ID, BYTES, BLOCKS 
FROM DBA_EXTENTS 
WHERE SEGMEHT_TYPE = 'INDEX' 
AND 01NER='HR' 
ORDER BY SEGMEHT_HAME; 



The query output is: 

SEGMENT NAME 



SEGMENT TYPE TABLESPACE NAME EXTENT ID 



BYTES 


BLOCKS 


65536 


32 


65536 


32 


65536 


32 


65536 


32 


65536 


32 


65536 


32 


65536 


32 


65536 


32 


65536 


32 


65536 


32 


65536 


32 


65536 


32 


65536 


32 



COUNTRY_C_ID_PK 

DEPT_ID_PK 

DEPT_LOCATION_IX 

EMP_DEPARTMENT_IX 

EMP_EMAIL_UK 

EMP_EMP_ID_PK 

EMP_JOB_IZ 

EMP_MANAGER_IZ 

EMP_NAME_IX 

JHIST_DEPARTMENT_IX 

JHIST_EMPLOYEE_IX 

JHIST_EMP_ID_ST_DATE_PK 

JHIST JOB IX 



INDEX 


EXAI>1PLE 


INDEX 


EXAMPLE 


INDEX 


EXAMPLE 


INDEX 


EXAMPLE 


INDEX 


EXAMPLE 


INDEX 


EXAMPLE 


INDEX 


EXAMPLE 


INDEX 


EXAMPLE 


INDEX 


EXAMPLE 


INDEX 


EXAMPLE 


INDEX 


EXAMPLE 


INDEX 


EXAMPLE 


INDEX 


EXAMPLE 
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JOB ID PK 




IHDEX 


EXAMPLE 


LOC CITY IX 




IHDEX 


EXAMPLE 


LOC_COUHTRY_IZ 




IHDEX 


EXAMPLE 


LOC ID PK 




IHDEX 


EXAMPLE 


LOC STATE PROVIHCE 


IX 


IHDEX 


EXAMPLE 


REG ID PK 




IHDEX 


EXAMPLE 



65536 


32 


65536 


32 


65536 


32 


65536 


32 


65536 


32 


65536 


32 





19 rows selected. 
For the lir schema, no segment has more than one extent allocated to it. 

Example 3: Displaying the Free Space (Extents) In a Tablespace 

Information about the free extents (extents not allocated to any segment) in a database 
is stored in the DBA_FREE_SPACE data dictionary view. For example, the following 
query reveals the amount of free space available as free extents in the SMUNDO 
tablespace: 

SELECT TABLESPACE_NAME, FILE_ID, BYTES, BLOCKS 
FROM DBA_FREE_SPACE 
WHERE TABLESPACE_HAME= ' SMDHDO ' ; 

The query output is: 



TABLESPACE. 


_NAME 


FILE_ID 


BYTES 


BLOCKS 


SMUMDO 






3 


55536 


32 


SMUNDO 






3 


55536 


32 


SMUNDO 






3 


55536 


32 


SMUNDO 






3 


55536 


32 


SMUNDO 






3 


55536 


32 


SMUNDO 






3 


55536 


32 


SMUNDO 






3 


131072 


64 


SMUNDO 






3 


131072 


64 


SMUNDO 






3 


55536 


32 


SMUNDO 






3 


3407872 


1664 


10 rows 


se'. 


Lee ted 









Example 4: Displaying Segments that Cannot Aliocate Addltlonai Extents 

It is possible that a segment cannot be allocated to an extent for anv of the following 
reasons; 

■ The tablespace containing the segment does not have enough room for the next 
extent. 

■ The segment has the maximum number of extents. 

■ The segment has the maximum number of extents allowed by the data block size, 
which is operating system specific. 

The following querv returns the names, owners, and tablespaces of all segments that 
satisfy any of these criteria: 

SELECT a.SEGMENT_NAHE, a .SEGMEHT_TYPE, a.TABLESPACE_NAME, a. OWNER 
FROM DBA_SEGMEHTS a 
WHERE a.HEXT_EXTENT >= {SELECT MAX{b. BYTES) 

FROM DBA_FREE_SPACE b 

WHERE b. TABLES PACE_HME = a .TABLESPACE_NAME) 
OR a. EXTENTS = a . MAX_EXTENTS 
OR a. EXTENTS = 'data block size' : 
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Note: When you use this query, replace data_jbiocA_size with 
the data block size for your system. 

Once you have identified a segment that cannot allocate additional extents, you can 
solve the problem in either of two ways, depending on its cause: 

■ If the tablespnce is full, add a datafile to the tablespace or extend the existing 
datafile. 

■ If the segment has too many extents, and you cannot increase MAXEXTEWTS for 
the segm.ent, perform the following steps. 

1. Export the data in the segment 

2. Drop and re-create the segment, giving it a larger INITIAL storage parameter 
setting so that it does not need to allocate so many extents. Alternatively, vou 
can adjust the PCTINCREASE and NEXT storage parameters to allow for more 
space in the segment. 

3. Import the data back into the segment. 

Capacity Planning for Database Objects 

Oracle Database provides two ways to plan capacitv for database objects: 

■ With Enterprise Manager 

■ With the DBMS_SPACE PL/SQL package 

This section discusses the PL/SQL method. Refer to Enterprise Manager onhne help 
and Oracle Database 2 Day DBA for details on capncit\' planning with Enterprise 
Manager 

Three procedures in the DBMS_SPACE package enable you to predict the size of new 
objects and monitor the size of existing database objects. This section discusses those 
procedures and contains the following sections: 

■ Estimating the Space Use of a Table 

■ Estimating the Space Use of an Index 

■ Obtaining Object Growth Trends 

Estimating the Space Use of a Table 

The size of a database table can \'arv greatly depending on tablespace storage 
attributes, tablespace block size, and many other factors. The CREATE_TABLE_COST 
procedure of the DBMS_3PACE package lets you estimate the space use cost of creating 
a table. Please refer to Oracle Database PL/SQL Packages and Types Reference for details 
on the parameters of this procedure. 

The procedure has two variants. The first variant uses average row size to estimate 
size. The second variant uses column information to estimate table size. Both variants 
require as input the following values: 

■ TABLESPACE_NAME: The tablespace in which the object will be created. The 
default is the SYSTEM tablespace, 

■ ROW_COUNT: The anticipated number of rows in the table. 
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■ PCT_FREE: The percentage of free space you want to reserve in each block for 
future expansion of existing rows due to updates. 

In addition, the first variant also requires as input a value for AVG_ROW_SIZE, which 
is the anticipated average row size in bytes. 

The second variant also requires for each anticipated column values for COLINFOS, 
which is an object type comprising the attributes COL_TYPE (the datatype of the 
column) and COL_SIZE (the number of characters or bytes in the column). 

The procedure returns two values: 

■ USED_BYTES: The actual bytes used by the data, including overhead for block 
metadata, PCT_FREE space, and so forth. 

■ ALLOC_BYTES: The amount of space anticipated to be allocated for the object 
taking into account the tablespace extent characteristics. 



Estimating the Space Use of an Index 



The CREATE_IHDEX_COST procedure of the DBMS_SPACE package lets you estimate 
the space use cost of creating an index on an existing table. 

The procedure requires as input the following values: 

■ DDL: The CREATE IHDEX statement that would create the index. The table 
specified in this DDL statement must be an existing table. 

■ [Optional] PLAN_TABLE: The name of the plan table to use. The default is NULL, 

The results returned by this procedure depend on statistics gathered on the segment. 
Therefore, be sure to obtain statistics shortly before executing this procedure. In the 
absence of recent statistics, the procedure does not issue an error, but it mav return 
inappropriate results. The procedure returns the following values: 

■ USED_BYTES: The number of bytes representing the actual index data, 

■ ALLOC_BYTES: The amount of space allocated for the index in the tablespace. 



Obtaining Object Growth Trends 



The OBJECT_GROWTH_TREHD procedure of the DBMS_SPACE package produces a 
table of one or more rows, where each row describes the space use of the object at a 
specific time. The procedure retrieves the space use totals from the Automatic 
Workload Repository or computes current space use and combines it with historic 
space use changes retrieved from Automatic Workload Repository, Please refer to 
[ARPLS] for detailed information on the parameters of this procedure. 

The procedure requires as input the following values: 

OBJECT_OWNER: The owner of the object, 

OBJECT_NAME: The name of the object, 

PARTITION_NAME: The name of the table or index partition, is relevant. Specify 
NULL otherwise, 

OBJECT_TYPE: The type of the object. 

START_TIME: A TIMESTAMP value indicating the beginning of the growth trend 
analvsis, 

END_TIME: A TIMESTAMP value indicating the end of the growth trend analysis. 
The default is "NOW", 
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■ INTERVAL: The length in minutes of the reporting interval during which the 
procedure should retrieve space use information. 

■ SKIP_INTERPOLATED: Determines whether the procedure should omit values 
based on recorded statistics before and after the IHTERVAL ('YES') or not ('NO'}, 
This setting is useful when the result table will be displayed as a table rather than 
a chart, because you can see more clearly how the actual recording interval relates 
to the requested reporting interval. 

The procedure returns a table, each of row of which provides space use information on 
the object for one interval. If the return table is very large, the results are pipelined so 
that another application can consume the information as it is being produced. The 
output table has the following columns: 

■ TIMEPOINT: A TIMESTAMP value indicating the time of the reporting interval. 

Records are not produced for values of TIME that precede the oldest recorded 
statistics for the object. 

■ SPACE_USAGE: The number of bytes actually being used bv the object data. 

■ SPACE_ALLOC: The number of bytes allocated to the object in the tablespace at 
that time. 

■ QUALITY: A value indicating how well the requested reporting interval matches 
the actual recording of statistics. This information is useful because there is no 
guaranteed reporting interval for object size use statistics, and the actual reporting 
interval varies over time and from object to object. 

The values of the QUALITY column are: 

- GOOD: The value whenever the value of TIME is based on recorded statistics 
with a recorded timestamp within 10% of the INTERVAL specified in the input 
parameters, 

INTERPOLATED: The value did not meet the criteria for GOOD, but was based 
on recorded statistics before and after the value of TIME, Current in-memorv 
statistics can be collected across all instances in a cluster and treated as the 
"recorded" value for the present time, 

PROJECTION: The value of TIME is in the future as of the time the table was 
produced. In an Oracle Real Application Clusters environment, the rules for 
recording statistics allow each instance to choose independently which objects 
will be selected. 

The output returned by this procedure is an aggregation of values recorded across 
all instances in a RAC environment. Each value can be computed from a 
combination of GOOD and INTERPOLATED values. The aggregate value returned is 
marked GOOD if at least 80% of that value was derived from GOOD instance values. 
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Managing Tables 



In this chapter; 
About Tables 

GuideUnes for Managing Tables 
Creating Tables 
Loading Tables 

Automatically Collecting Statistics on Tables 
Altering Tables 
Redefining Tables Online 

Researching and Reversing Erroneous Table Changes 
Recovering Tables Using Oracle Flashback Table 
Dropping Tables 

Using Flashback Drop and Managing the Recvcle Bin 
Managing Index -Organized Tables 
Managing External Tables 
Tables Data Dictionarv Vievi's 



About Tables 



Tables are the basic unit of data storage in an Oracle Database, Data is stored in rows 
and columns. You define a table with a table name, such as employees, and a set of 
columns. You give each column a column name, such as emploYee_id, las t_nai[ie, 
and job_id; a datat}'pe, such as VARCHAR2. DATE, or NUMBER; and a width. The 
width can be predetermined bv the datatvpe, as in DATE, If columns are of the NUMBER 
datatvpe, define precision and scale instead of width, A row is a collection of column 
information corresponding to a single record. 

You can specifv rules for each column of a table. These rules are called integrity 
constraints. One example is a NOT NULL integrity constraint. This constraint forces the 
column to contain a value in every row. 

You can invoke transparent data encryption to encr}"pt data before storing it If users 
attempt to circumvent the database access control mechanisms by looking inside 
Oracle datafiles directlv with operating svstem tools. encr\'ption prevents these users 
from viewing sensitive data. 
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Tables can also include virtual columns. A virtual column is like anv other t.ible 
column, except that its value is derived bv evaluating an expression. The expression 
can include columns from the same table, constants, SQL functions, and user-defined 
PL /SQL functions. You cannot explicitly virite to a virtual column. 

After you create a table, you insert rows of data using SQL statements or using an 
Oracle bulk load utility. Table data can then be queried, deleted, or updated using 
SQL. 

See Also: 



Oracle Database Concepts for a more detailed description of 
tables 

Orack' Database SQL Language Reference for descriptions of 
Oracle datatypes 

Chapter 17, "Managing Space for Schema Objects" for 
guidelines for managing space for tables 

Chapter 16, "Managing Schema Objects" for information on 
additional aspects of managing tables, such as specifying 
integrity constraints and analyzing tables 

Oracle Database Advanced Security Administrator's Guide for a 
discussion of transparent data encryption 



Guidelines for l\/lanaging Tables 



This section describes guidelines to follow when managing tables. FoUowing these 
guidelines can make the management of your tables easier and can improve 
performance when creating the table, as well as when loading, updating, and quer\'ing 
the table data. 

The following topics are discussed; 

Design Tables Before Creating Them 

Consider Your Options for the Type of Table to Create 

Specify the Location of Each Table 

Consider Parallelizing Table Creation 

Consider Using NOLOGGING When Creating Tables 

Consider Using Table Compression 

Consider Encrv'pting Columns That Contain Sensitive Data 

Estimate Table Size and Plan Accordingly 

Restrictions to Consider When Creating Tables 



Design Tables Before Creating Them 



Usually the application developer is responsible for designing the elements of an 
application, including the tables. Database administrators are responsible for 
establishing the attributes of the underlying tablespace that will hold the application 
tables. Either the DBA or the applications developer, or both working jointly, can be 
responsible for the actual creation of the tables, depending upon the practices for a 
site. 
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Working with the application developer, consider the following guidelines when 
designing tables: 

Use descriptive names for tables, columns, indexes, and clusters. 

Be consistent in abbreviations and in the use of singular and plural forms of table 
names and columns. 

Document the meaning of each table and its columns with the COMMENT 
command. 

Normalize each table. 

Select the appropriiite datiitype for each column. 

Consider whether vour applications would benefit from adding one or more 
virtual columns to some tables. 

Define columns that allow nulls last, to conserve storage space. 

Cluster tables whenever appropriate, to conserve stomge space and optimize 
performance of SQL statements. 

Before creating a table, \'ou should also determine whether to use integrity' constraints. 
Integrity constraints can be defined on the columns of a table to enforce the business 
rules of your database automatically. 



Consider Your Options for the Type of Table to Create 

What types of tables can vou create? Here are some choices: 



Type of Table 



Description 



Ordinary 
(heap-organized) table 

Clustered table 



Index- organized table 



This is the basic, general purpose type of table which is the primary 
subject of this chapter. Its data is stored as an unordered collection 
(heap) 

A clustered table is a table that is part of a cluster. A cluster is a 
group of tables that share the same data blocks because they share 
common columns and are often used together 

Clusters and clustered tables are discussed m Chapter 20, 
"Managing Clusters", 

Unlike an ordinary (heap-organized) table, data for an 
index-organized table is stored in a B-tree index structure in a 
primary key sorted manner Besides storing the primary key 
column values of an index-organized table row, each index entry in 
the B-tree stores the nonkey column values as well. 

Index- organized tables are discussed in "Managing 
Index-Organized Tables" on page 18-49, 

Partitioned table Partitioned tables allow your data to be broken down into smaller, 

more manageable pieces called partitions, or even subpartitions. 
Each partition can be managed individually, and tan operate 
independently of the other partitions, thus providing a structure 
that can be better tuned for availability and performance. 

Partitioned tables are discussed in Oracle Database VLDB and 
Partitioning Guide. 



Specify the Location of Each Table 



It is advisable to specify the TABLESPACE clause in a CREATE TABLE statement to 
identify the tablespace that is to store the new table. Ensure that vou have the 
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appropriate privileges and quota on .iny tablespaces that voii use. If vou do not 
specify a tablespace in a CREATE TABLE statement, the table is created in your default 
table space. 

When specif}"ing the tablespace to contain a new table, ensure that vou understand 
implications of your selection. Bv properlv specifying a tablespace during the creation 
of each table, you can increase the performance of the database system and decrease 
the time needed for database administration. 

The following situations illustrate how not specifying a tablespace, or specifying an 
inappropriate one, can affect performance: 

■ If users' objects are created in the SYSTEM tablespace, the performance of the 
database can suffer, since both data dictionarv objects and user objects must 
contend for the same datafiles. Users' objects should not be stored in the SYSTEM 
tablespace. To avoid this, ensure that all users are assigned default tablespaces 
when thev are created in the database. 

■ If application-associated tables are arbitrarilv stored in various tablespaces, the 
time necessar}' to complete administrative operations (such as backup and 
recovery) for the data of that application can be increased. 

Consider Parallelizing Table Creation 

You can utilize parallel execution when creating tables using a subquery (AS SELECT) 
in the CREATE TABLE statement. Because multiple processes work together to create 
the table, performance of the table creation operation is improved. 

Parallelizing table creation is discussed in the section "Parallelizing Table Creation " on 
page 18-11. 

Consider Using NOLOGGING When Creating Tables 

To create a table most efficiently use the NOLOGGIHG clause in the CREATE 
TABLE ... AS SELECT statement. The NOLOGGING clause causes minimal redo 
information to be generated during the table creation. This has the following benefits: 

■ Space is saved in the redo log files. 

■ The time it takes to create the table is decreased. 

■ Performance improves for parallel creation of large tables. 

The NOLOGGING clause also specifies that subsequent direct loads using SQL*Loader 
and direct load INSERT operations are not logged. Subsequent DML statements 
(UPDATE, DELETE, and conventional path insert) are unaffected by the NOLOGGING 
attribute of the table and generate redo. 

If you cannot afford to lose the table after vou have created it (for example, vou will no 
longer have access to the data used to create the table) vou should take a backup 
immediately after the table is created. In some situations, such as for tables that are 
created for temporary use, this precaution may not be necessary. 

In general, the relative performance improvement of specif}'ing NOLOGGING is greater 
for larger tables than for smaller tables. For small tables, NOLOGGING has little effect 
on the time it takes to create a table. However, for larger tables the performance 
improvement can be significant, especially when you are also parallelizing the table 
creation. 
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Consider Using Table Compression 



As vour database grows in size to gigabytes or terabytes and beyond, consider using 
table compression. Table compression saves disk space and reduces memory use in 
the buffer cache. Table compression can also speed up querv execution during reads. 
There is, however, a cost in CPU overhead for data loading and DML. Table 
compression is completely transparent to applications. It is especially useful in online 
analytical processing (OLAP) svstems, where there are lengthv read-only operations, 
but can also be used in online transaction processing (OLTP) systems. 

You specify table compression with the COMPRESS clause of the CREATE TABLE 
statement. You can enable compression for an existing table bv using this clause in an 
ALTER TABLE statement. In this case, the only data that is compressed is the data 
inserted or updated after compression is enabled. Similarly, you can disable table 
compression for an existing compressed table with the ALTER TABLE, ..NOCOMPRESS 
statement. In this case, all data the was already compressed remains compressed, and 
new data is inserted uncompressed. 

You can enable compression for aU table operations or vou can enable it for direct-path 
inserts only. When compression is enabled for all operations, compression occurs 
during all DML statements and when data is inserted with a bulk (direct-path) insert 
operation. To enable compression for conventional DML, you must set the 
COMPATIBLE initialization parameter to 11,1,0 or higher. 

To enable compression for all operations you must use the COMPRESS FOR ALL 
OPERATIONS clause. To enable compression for direct-path inserts only, you use the 
COMPRESS FOR DIRECT_LOAD OPERATIONS clause. The keyword COMPRESS by itself 
is the same as the clause COMPRESS FOR DIRECT_LOAD OPERATIONS, and invokes the 
same compression behavior as previous database releases. 

Adding and Dropping Columns in Compressed Tables 

When you enable compression for all operations on a table, you can add and drop 
table columns. If you enable compression for direct-path inserts only, you cannot drop 
columns, and you can add columns only if you do not specify default values. 

Examples 

The following example enables compression for all operations on the table 
transaction, which is used in an OLTP application: 

CREATE TftBLE transaction ( ,,. ) COMPRESS FOR ALL OPERATIOMS ; 

The next two examples enable compression for direct-path insert only on the 
sales_historY table, which is a fact table in a data warehouse: 

CREATE TABLE sales.history { .., ) COMPRESS FOE DIEECT_LOAD OPERATIONS; 
CREATE TABLE sales.history { .., ) COMPRESS; 

Compression and Partitioned Tables 

You can enable or disable compression at the partition level. You can therefore have a 
table with both compressed and uncompressed partitions. If the compression settings 
for a table and one of its partitions disagree, the partition setting has precedence for 
the partition. In the following example, all partitions except the northeast partition 
are compressed. 

CREATE TABLE sales 

[saleskey number, 

quarter number. 



Managing Tables 1 8-5 



Guidelines lor Managing Tabies 



product number, 
salesperson number, 
amount number (12, 2), 
region varchar2 (ID) ) COMPRESS 
PARTITION BY LIST (region) 

(PARTITION northwest VALUES ( 'MORTHWEST' ) , 
PARTITION southwest VALUES ('SOUTHWEST'), 
PARTITION northeast VALUES {'NORTHEAST') NOCOMPRESS, 
PARTITION southeast VALUES ('SOUTHEAST'), 
PARTITION western VALUES ( 'hESTERB' ) ) ; 

Determining If a Table is Compressed 

In the '^_TABLE3 data dictionary views, compressed tables liave ENABLED in the 
COMPRESSION column. For partitioned tables, this column is nuU, and the 
COMPRESSION column of the ■'_TAB_PARTITIONS data dictionary view indicates the 
partitions that are compressed. In addition, the COMPRESS_FOR column indicates 
whether the table is compressed FOR ALL OPERATIONS or for DIRECT LOAD ONLY. 

SgL> SELECT table_name, compression, compresE_Eor FROM user_tables ; 

TABLEJAME COMPRESS COMPRESS_F0R 

Tl DISABLED 

T2 EHABLED DIRECT LOAD ONLY 

T3 ENABLED FOR ALL OPERATIONS 

See Also: 

■ Orack' Database SQL Language Reference for more details on the 

CREATE TABLE. ..COMPRESS and ALTER TABLE. ..COMPRESS 

statements, including restrictions 

■ Oracle Database VLDB and Partitioning Guide for more information 
on table partitioning 

■ "Inserting Data Into Tables Using Direct-Path INSERT" on 
page 18-16 

Consider Encrypting Coiumns Tliat Contain Sensitive Data 

You can encrvpt individual table columns that contain sensitive data. Examples of 
sensitive data include social securit}" numbers, credit card numbers, and medical 
records. Column encrvption is transparent to your applications, with some 
restrictions. 

Although encryption is not meant to solve all security problems, it does protect your 
data from users who tr\' to circumvent the security' features of the database and access 
database files directly through the operating system file system. 

Column encryption uses the transparent data encryption feature of Oracle Database, 
which requires that vou create an Orack wallet to store the master encrvption kev for 
the database. The wallet must be open before you can create a table with encr\'pted 
columns and before you can store or retrieve encrypted data. When vou open the 
wallet, it is available to all sessions, and it remains open until you explicitlv close it or 
until the database is shut down. 

Transparent data encrvption supports industrv-standard encrvption algorithms, 
including the following Advanced Encrvption Standard (AES) and Triple Data 
Encrvption Standard (3DES) algorithms: 

. 3DES168 
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. AES128 

. AES192 

. AES256 

You choose the algorithm, to use when you create the t.ible. All encrypted columns in 
the table use the same algorithm. The default is AES192, The encryption kev length is 
implied by the algorithm name. For example, the AES128 algorithm uses 128-bit keys. 

If vou plan on encrv'pting many columns in one or more tables, vou may want to 
consider encrypting an entire tablespace instead and storing these tables in that 
tiiblespace. Tablespace encryption, which also uses the transparent data encryption 
feature but encrypts at the physical block le\el, can perform better than encrypting 
many columns. Another reason to encrypt at the tablespace level is to address the 
following limitations of column encryption: 

■ If the COMPATIBLE initialization parameter set to 10.2,0, which is the minim um 
setting to enable transparent data encryption, data from encrypted columns that is 
inyolyed in a sort or hash-join and that must be written to a temporary' tablespace 
is written in clear text, and thus exposed to attacks. You must set COMPATIBLE to 
11,1,0 or higher to ensure that encr\'p ted data written to a temporary tablespace 
remains encrypted. Note that as long as COMPATIBLE is set to 10,2,0 or higher, 
data from encrypted columns remains encrypted when written to the undo 
tablespace or the redo log, 

■ Certain data types, such as object data types, are not supported for column 
encryption, 

■ You caruiot use the transportable tablespace feature for a tablespace that includes 
tables with encrypted columns, 

■ Other restrictions, which are detailed in Oracle Database Advanced Securil^ 
Adiiihiiilralor's Guide. 

See Also: 

■ "Encrypted Tablespaces" on page 12-8 

■ "Example: Creating a Table" on page 18-8 

■ Oracle Database Advanced Security Administrator's Guide for moie 
information about transparent data encryption and for 
instructions for creating and opening wallets 

■ Oracle Database SQL Language Reference for information about the 

CREATE TABLE statement 

■ Oracle Real Application Clusters Administration and Deployment 
Guide for information on using an Oracle wallet in an Oracle Real 
Application Clusters environment 

■ "Transporting Tablespaces Betiveen Databases" on page 12-29 



Estimate Table Size and Pian Accordingiy 



Estimate the sizes of tables before creating them. Preferably, do this as part of database 
planning. Knowing the sizes, and uses, for database tables is an important part of 
database planning. 

You can use the combined estimated size of tables, along with estimates for indexes, 
undo space, and redo log files, to determine the amount of disk space that is required 
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to hold an intended database. From these estimates, vou can make correct hardware 
purchases. 

You can use the estimated size and growth rate of an individual table to better 
determine the attributes of a tablespace and its underlying datafiles that are best suited 
for the table. This can enable vou to more easily manage the table disk space and 
improve I/O performance of applications that use the table. 

Restrictions to Consider When Creating Tables 

Here are some restrictions that mav affect your table planning and usage: 

■ Tables containing object types cannot be imported into a pre-Oracle8 database. 

■ You cannot merge an exported table into a preexisting table having the same name 
in a different schema. 

■ You cannot move types and extent tables to a different schema when the original 
data still exists in the database. 

■ Oracle Database has a limit on the total number of columns that a table (or 
attributes that an object Wpe) can have. See Oracle Database Reference for this limit 

Further, when you create a table that contains user-defined type data, the database 
maps columns of user-defined type to relational columns for storing the 
user-defined t\'pe data. This causes ndditionnl relational columns to be created. 
This results in "hidden" relational columns that are not visible in a DESCRIBE 
table statement and are not returned by a SELECT ' statement. Therefore, when 
you create an object table, or a relational table with columns of REF, varrav, nested 
table, or object t\'pe, be aware that the total number of columns that the database 
actually creates for the table can be more than those you specify. 

See Also: Oracle Database Object-Relational Developer's Guide for 
m.oie information about user-defined types 
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To create a new table in vour schema, you must have the CREATE TABLE system 
privilege. To create a table in another user's schema, you must have the CREATE ANY 
TABLE system privilege. Additionally, the owner of the table must have a quota for the 
tablespace that contains the table, or the UNLIMITED TABLESPACE system privilege. 

Create tables using the SQL statement CREATE TABLE. 

This section contains the following topics: 

■ Example: Creating a Table 

■ Creating a Temporary Table 

■ Parallelizing Table Creation 

See Also: Oracle Database SQL Language Refcrena for exact svntax 
of the CREATE TABLE and other SQL statements discussed in this 
chapter 



Example: Creating a Table 



When you issue the following statement, you create a table named adTnin_enip in the 
hr schema and store it in the admin_tbE tablespace with an initial extent size of 50K: 

CREATE TABLE hr . ad!iiin_emp ( 
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empno HUHBER(5} PRIMMiY KEY, 

ename VAECHfiE2(15) NOT NULL, 

ssn MUMBER(9} ENCRYPT, 

job VARCHAR2(10) , 

mgr MUMBER ( 5 } , 

hiredate DATE DEFAULT (sysdate) , 

photo BLOB, 

sal MUMBER (7, 2) , 

hrly_rate miMBER(7,2) GENERATED ALWAYS AS (sal/20aO) , 

comm lUHBER (7.2], 

deptno HUHBER(3} NOT NULL 

COHSTRAINT admiri_dept_fkey REFERENCES hr .departments 
[ depar tment_id ) ) 
TABLESPACE admin_tbs 
STORAGE ( INITIAL 50K) ,- 

Note the following about this example: 

■ Integrity constraints are defined on several columns of the table. 

■ Encryption is defined on one column (s sn), through the transparent data 
encryption feature of Oracle Database. The Oracle Wallet must therefore be open 
for this CREATE TABLE statement to succeed, 

■ The photo column is of data t\'pe BLOB, which is a member of the set of data 
types called large objects (LOBs). LOBs are used to store semi-structured data 
(such as an XML tree) and unstructured data (such as the stream of bits in a color 
image). 

■ One column is defined as a virtual column (hrly_rate). This column computes 
the employee's hourly rate as the yearly salary divided by 2,080. 



See Also: 



Oracle Database SQL Language Reference for a description of the 
datatypes that can be specified for columns 

"Managing Integrity Constraints" on page 16-9 

Oracle Database Advanced Security Administrator's Guide for 
information on transparent data encryption and the Oracle 
Wallet 

Oracle Database SecureFiles and Large Objects Developer's Guide 
for more information on LOBs. 

Oracle Database SQL Language Reference for information on rules 
for yirtual columns 



Creating a Temporary Table 



Temporary tables are useful in applications where a result set is to be buffered 
(temporarily persisted), perhaps because it is constructed by running multiple DML 
operations. For example, consider the following: 

A Web-based airlines reservations application allows a customer to create several 
optional itineraries. Each itinerary is represented by a row in a temporary table. The 
application updates the rows to reflect changes in the itineraries. When the customer 
decides which itinerary she wants to use, the application moves the row for that 
itinerary to a persistent table. 
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During the session, the itinerary data is private. At the end of the session, the optional 
itineraries are dropped. 

The definition of a temporar}' table is visible to all sessions, but the data in a 
temporary table is visible only to the session that inserts the data into the table. 

Use the CREATE GLOBAL TEMPORARY TABLE statement to create a temporary table. 
The ON COMMIT clause indicates if the data in the table is transaction-specific (the 
default) or session-specific, the implications of which are as follows: 

ON COMMIT Setting Implications 

DELETE ROWS This creates a temporary table that is transaction specific. A 

session becomes bound to the temporary table with a 
transactions first insert into the table. The binding goes away at 
the end of the transaction. The database truncates the table 
(delete all rows) after each commit. 

PRESERVE ROWS This creates a temporary table that is session specific. A session 

gets bound to the temporary table with the first insert into the 
table in the session. This binding goes away at the end of the 
session or by issuing a TRUNCATE of the table in the session. The 
database truncates the table when you terminate the session. 

This statement creates a temporary table that is transaction specific: 

CliEATE GLOBAL TEMPORARY TABLE adniin_work_area 
{startdate DATE, 
enddate DATE, 
class CHAR{20) ) 
ON COMMIT DELETE ROWS; 

Indexes can be created on temporary tables. They are also temporary and the data in 
the index has the same session or transaction scope as the data in the underlying table. 

By default, rows in a temporary table are stored in the default temporary tablespace of 
the user who creates it. However, you can assign a temporary table to another 
tablespace upon creation of the temporary table by using the TABLESPACE clause of 
CREATE GLOBAL TEMPORARY TABLE, You can use this feature to conserve space 
used bv temporary tables. For example, if you need to perform many small temporary 
table operations and the default temporary tablespace is configured for sort operations 
and thus uses a large extent size, these small operations will consume lots of 
unnecessary disk space. In this case it is better to allocate a second temporary 
tablespace with a smaller extent size. 

The following two statements create a temporar}' tablespace with a 64 KB extent size, 
and then a new temporary table in that tablespace, 

CREATE TEMPORARY TABLESPACE tbs_tl 

TEMPFILE 'tbs_tl,f' SIZE 50m REUSE AUTOEXTEND ON 

MMSIZE UNLIMITED 

EXTENT MANAGEMENT LOCAL UNIFORM SIZE 64K; 

CREATE GLOBAL TEMPORARY TABLE adniin_work_area 
(startdate DATE, 
enddate DATE, 
class CHAR{20] ) 
ON COMMIT DELETE ROWS 
TABLESPACE tbs_tl; 
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See Also: "Temporarv Tabiespaces" on page 12-10 



UnJike permanent tables, temporary tables and their indexes do not automatically 
allocate a segment when thev are created. Instead, segments are allocated when the 
first INSERT (or CREATE TABLE AS SELECT) is performed. This means that if a 
SELECT, UPDATE, or DELETE is performed before the first INSERT, the table appears 
to be empty. 

DDL operations (except TRUHCATE) are allowed on an existing temporary table only if 
no session is currently bound to that temporary table. 

If vou rollback a transaction, the data you entered is lost, although the table definition 
persists. 

A transaction-specific temporary table allows onlv one transaction at a time. If there 
are several autonomous transactions in a single transaction scope, each autonomous 
transaction can use the table only as soon as the previous one commits. 

Because the data in a temporan' table is, by definition, temporan', backup and 
recover)' of temporary table data is not available in the event of a system faUure. To 
prepare for such a failure, you should develop alternative methods for preserving 
temporarv table data. 



Parallelizing Table Creation 



When vou specifv the AS SELECT clause to create a table and populate it with data 
from another table, vou can utilize parallel execution. The CREATE TABLE . . . AS 
SELECT statement contains two parts: a CREATE part (DDL) and a SELECT part 
(qnerv). Oracle Database can parallelize both parts of the statement. The CREATE part 
is parallelized if one of the following is true: 

■ A PARALLEL clause is included in the CREATE TABLE ... AS SELECT statement 

■ AnALTER SESSION FORCE PARALLEL DDL statement is specified 
The query part is parallelized if all of the following are true: 

■ The query includes a parallel hint specification (PARALLEL or PARALLEL_INDEX) 
or the CREATE part includes the PARALLEL clause or the schema objects referred to 
in the query have a PARALLEL declaration associated with them. 

■ At least one of the tables specified in the quer\' requires either a full table scan or 
an index range scan spanning multiple partitions. 

If vou parallelize the creation of a table, that table then has a parallel declaration (the 
PARALLEL clause) associated vi'ith it. Any subsequent DML or queries on the table, for 
which parallelization is possible, will attempt to use parallel execution. 

The following simple statement parallelizes the creation of a table and stores the result 
in a compressed format, using table compression: 

CREATE TABLE hr . adinin_emp_dept 
PARALLEL COMPRESS 
AS SELECT ' FROM hr . employees 
MHERE depart:ment_id = 10; 

In this case, the PARALLEL clause tells the database to select an optimum number of 
parallel execution ser\'ers when creating the table. 
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See Also: 



Orach' Database Concepts for more information about parallel 
execution 

Oracle Database Data Warehousing Guide for a detailed discussion 
about using parallel execution 

"Managing Processes for ParaUel SQL Execution" on page 4-19 



There are several means of inserting or initially loading data into vour tables. Most 
commonly used are the following: 



Method 



Description 



SQL 'Loader This Oracle utility program loads data from external files into 

tables of an Oracle Database. 

For information about SQL 'Loader, see Orncb' Dalalmse 
Utiliths. 

CREATE TABLE... AS SELECT Using this SQL statement you can create a table and populate 
statement (CTAS) it with data selected from another existing table. 



IHSERT statement 



MERGE statement 



The IHSERT statement enables you to add rows to a table, 
either by specif\'ing the column values or by specifying a 
subquery that selects data from another existing table. 

The HEIRGE statement enables you to insert rows into or 
update rows of a table, bv selecting rows from another 
existing table. If a row in the new data corresponds to an item 
that already exists in the table, then an UPDATE is performed, 
else an IHSERT is performed. 



See Oracle Database SQL Language Reference for details on the CREATE TABLE ,,, AS 
SELECT, INSERT, and MERGE statements. 



Inserting Data with DML Error Logging 



When you load a table using an INSERT statement with subquery, if an error occurs, 
the statement is terminated and rolled back in its entirety. This can be wasteful of time 
and system resources. For such INSERT statements, you can ayoid this situation by 
using the DML error logging feature. 

To use DML error logging, you add a statement clause that specifies the name of an 
error logging table into which the database records errors encountered during DML 
operations. When you add this error logging clause to the INSERT statement, certain 
t}'pes of errors no longer terminate and roll back the statement. Instead, each error is 
logged and the statement continues. You then take correctiye action on the erroneous 
rows at a later time. 

DML error logging works with INSERT, UPDATE, MERGE, and DELETE statements. 
This section focuses on INSERT statements. 

To insert data with DML error logging: 

1. Create an error logging table. (Optional) 

You can create the table manually or use the DBMS_ERRLOG package to 
automatically create it for you. See "Creating an Error Logging Table" on 
page 18-15 for details. 
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2. Execute an INSERT statement and include an error logging clause. This clause: 

■ Optionallv references the error logging table that vou created. If vou do not 
provide an error logging table name, the database logs to an error logging 
tiible with a default name. The default error logging table name is EER3_ 
followed by the first 25 characters of the name of the table that is being 
inserted into. 

■ Optionallv includes a tag (a numeric or string literal in parentheses) that gets 
added to the error log to help identify the statement that caused the errors. If 
the tag is omitted, a NULL value is used, 

■ Optionally includes a REJECT LIMIT subclause. 

This subclause indicates the maximum number of errors that can be 
encountered before the INSERT statement terminates and rolls back. You can 
also specifv UNLIMITED, The default reject limit is zero, which means that 
upon encountering the first error, the error is logged and tlie statement rolls 
back. For parallel DML operations, the reject limit is applied to each parallel 



Note: If the statement exceeds the reject limit and roUs back, the 
error logging table retains the log entries recorded so far. 



See Oracle Database SQL Language Reference for error logging clause syntax 
information. 

3. Querv the error logging table and take corrective action for the rows that 
generated errors. 

See "Error Logging Table Format", later in this section, for details on the error 
logging table structure. 

Example The following statement inserts rows into the DW_EMPL table and logs 
errors to the ERR_EMPL table. The tag 'daily_load' is copied to each log entry. The 
statement terminates and rolls back if the number of errors exceeds 25, 

INSERT IHTO dw_einpl 

SELECT employee_id, firstjiame, lastjianie, hire_date, salary, department_id 

FROM employees 

WHERE hire_date > sysdate - 7 

LOG ERRORS INTO err_empl { 'dailyjoad' ) REJECT LIMIT 25 

For more examples, see Oracle Database SQL Language Reference and Oracle Database 

Dnta Warehousing Guide. 

Error Logging Table Format 

The error logging table consists of two parts: 

■ A mandatorv set of columns that describe the error. For example, one column 
contains the Oracle error number. 

Table 18-1 lists these error description columns, 

■ An optional set of columns that contain data from the row that caused the error. 
The column names match the coliunn names from the table being inserted into 
(the "DML table"). 
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The number of columns in this part of tlie error logging table can be zero, one, or 
more, up to the number of columns in the DML table. If a column exists in the 
error logging table that has the same name as a column in the DML table, the 
corresponding data from the offending row being inserted is written to this error 
logging table column. If a DML table column does not have a corresponding 
column in the error logging table, the column is not logged. If the error logging 
table contains a column with a name that does not match a DML table column, the 
column is ignored. 

Because tvpe conversion errors are one t\'pe of error that might occur, the data 
types of the optional columns in the error logging table must be t\'pes that can 
capture any value without data loss or conversion errors. (If the optional log 
columns were of the same types as the DML table columns, capturing the 
problematic data into the log could suffer the same data conversion problem that 
caused the error) The database makes a best effort to log a meaningful value for 
data that causes conversion errors. If a value cannot be derived, NULL is logged for 
the column. An error on insertion into the error logging table causes the statement 
to terminate. 

Table 18-2 lists the recommended error logging table column data t\'pes to use for 
each data t\'pe from the DML table. These recommended data t\'pes are used 
when vou create the error logging table automatically with the DBMS_ERRLOG 
package. 

Table 18-1 Mandatory Error Description Columns 



Column Name 


Data Type Description 


ORA_ERR_miMBERS 


HDMBER Oracle error number 


ORA_EHR_MESG$ 


VARCHAH2 (2 000) Oracle errormessage text 


ORA_EER_ROWIDS 


ROWID Rowid of the row in error (for update and 
delete] 



ORA_EER_OPTYPS VAECHAE2 { 2 ; 



Type of operation: insert (I), update (U), 
delete (D) 

Note: Errors from the update clause and 
insert clause of a MERGE operation are 
distinguished by the U and I values. 



ORA_EHR_TAGS 


VARCHAH2 (2 000) Value of the tag supplied by the user in 
the error logging c ause 


Table 18-2 Error Logging Table Column Data 


1 Types 


DML Table Column 
Type 


Error Logging Table 
Column Type 


Notes 


HUMBEH 


VARCHAR2 (4000) 


Able to log conversion errors 


CHaR/VaRCHaR2 (n) 


VARCHAR2 (4000) 


Logs any value without information loss 


HCHAR/NVi\RCHAR2 [ 


n] NVAHCHAR2 (4000) 


Logs any value without information loss 


DATE/TTMRSTAMP 


VARCHAR2 (4000) 


Logs any value without information loss. 
Converts to character format with the 
default date/time format mask 


RAW 


RAW (2000) 


Logs any value without information loss 


ROWID 


UROWID 


Logs any rowid type 


LONG/ LOB 




Not supported 
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Table 18-2 (Cont.) Error Logging Table Column Data Types 

DML Table Column Error Logging Table 

Type Column Type Notes 

User-defined types Not supported 

Creating an Error Logging Table 

You can create an error logging table manuaUy, or you. can use a PL /SQL package to 
automatically create one for you. 

Creating an Error Logging Table Automatically You use the dbms_errlog package to 
automatically create an error logging table. The CREflTE_ERROR_LOG procedure 
creates an error logging table with nil of the mandatorv error description columns plus 
all of the columns from the named DML table, and performs the data type mappings 
shown in Table 18-2. 

The following statement creates the error logging table used in the previous example. 

EXECUTE DBMS_ERRLOG.CHEATE_ERRDE_LOG( 'D1_EMPL' , 'ERR_EMPL' } ; 

See Oracle Database PL/SQL Packages and Types Reference for details on DBMS_ERRLOG. 

Creating an Error Logging Table IVIanually You use standard DDL to manually create the 
error logging table. See "Error Logging Table Format" on page 18-13 for table structure 
requirements. You must include all mandator)' error description columns. They can be 
in anv order, but must be the first columns in the table. 

Error Logging Restrictions and Caveats 

Oracle Database logs the following errors during DML operations: 

Column values that are too large 

Constraint violations (NOT NULL, unique, referentiaL and check constraints) 

Errors raised during trigger execution 

Errors resulting from type conversion between a column in a subquery and the 
corresponding column of the table 

Partition mapping errors 

Certain MERGE operation errors (ORA -30926: Unable to get a stable set of rows for 
MERGE operation.) 

Some errors are not logged, and cause the DML operation to terminate and roll back. 
For a list of these errors and for other DML logging restrictions, see the discussion of 
the error_logging_clause in the INSERT section of Oracle Database SQL Language 
Reference. 

Space Considerations Ensure that vou consider space requirements before using DML 
error logging. You require available space not only for the table being inserted into, 
but also for the error logging table. 

Security The user who issues the INSERT statement with DML error logging must 
have INSERT privileges on the error logging table. 

See Also: Oracle Database SQL Language Reference and Oracle 
Database Data Warcliousing Guide for DML error logging examples. 
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Inserting Data Into Tables Using Direct-Path INSERT 

Oracle Database inserts data into a table in one of two ways: 

■ During conventional INSERT operations, the database reuses free space in the 
table, interleaving newly inserted data with existing data. During such operations, 
the database also maintains referential integrity constraints. 

■ During direct-path INSERT operations, the database appends the inserted data 
after existing data in the table. Data is written directly into datafiles, bypassing the 
buffer cache. Free space in the existing data is not reused, and referential integrity 
constraints are ignored. These procedures combined can enhance performance. 

Further, the data can be inserted either in serial mode, where one process executes the 
statement, or parallel mode, where multiple processes work together simultaneously 
to run a single SQL statement. The latter is referred to as parallel execution. 

This section discusses one aspect of inserting data into tables. Specifically, using the 
direct-path form of the INSERT statement. It contains the following topics: 

Advantages of Using Direct-Path INSERT 

Enabhng Direct-Path INSERT 

How Direct-Path INSERT Works 

Specifying the Logging Mode for Direct-Path INSERT 

Additional Considerations for Direct-Path INSERT 



Note: Only a few details and examples of inserting data into 
tables are included in this book, Oracle documentation specific to 
data warehousing and application development provide more 
extensive information about inserting and manipulating data in 
tables. For example: 

■ Oracis Database Data Wareliousing Guide 

■ Orack Database Advanced Application Developer's Guide 

■ Orack Database SecureFiks and Large Objects Developer's Guide 

Advantages of Using Direct-Path INSERT 

The following are performance benefits of direct-path INSERT: 

■ During direct-path INSERT, you can disable the logging of redo and undo entries. 
Conventional insert operations, in contrast, must always log such entries, because 
those operations reuse free space and maintain referential integritv', 

■ To create a new table with data from an existing table, you have the choice of 
creating the new table and then inserting into it, or executing a CREATE TABLE .,. 
AS SELECT statement By creating the table and then using direct-path INSERT 
operations, you update any indexes defined on the target table during the insert 
operation. The table resulting from a CREATE TABLE ,,, AS SELECT statement, in 
contrast, does not have any indexes defined on it; you must define them later 

■ Direct-path INSERT operations ensure atomicit\' of the transaction, even when run 
in parallel mode. Atomicity cannot be guaranteed during parallel direct-path loads 
(using SQL 'Loader), 
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■ If errors occur during parallel direct-path loads, some indexes could be marked 
UNUSABLE at the end of the load. Parallel direct-path INSERT, in contrast, rolls 
back the statement if errors occur during index update. 

■ Direct-path INSERT must be used if you want to store the data in compressed 
form using table compression. 

Enabling Direct-Path INSERT 

You can implement direct-path INSERT operations bv using direct-path INSERT 
statements, inserting data in parallel mode, or by using the Oracle SQL'Loader utilit}' 
in direct-path mode. Direct-path inserts can be done in either serial or parallel mode. 

To activate direct-path INSERT in serial mode, you must specify the APPEND hint in 
each INSERT statement, either immediately after the INSERT keyword, or 
immediately after the SELECT keyword in the subquery of the INSERT statement. 

When you are inserting in parallel DML mode, direct-path INSERT is the default. In 
order to run in parallel DML mode, the following requirements must be met: 

■ You must have Oracle Enterprise Edition installed, 

■ You must enable parallel DML in your session. To do this, run the following 
statement: 

ALTER SESSION { ENABLE | FORCE ) PAEALLEL DML; 

■ You must specify the parallel attribute for the target table, either at create time or 
subsequently, or you must specify the PARALLEL hint for each insert operation. 

To disable direct-path INSERT, specify the NOAPPEND hint in each INSERT statement. 
Doing so overrides parallel DML mode. 



Notes: 



Direct-path INSERT supports only the subquerv syntax of the 
INSERT statement, not the VALUES clause. For more 
information on the subquery syntax of INSERT statem.ents, see 
Oracle Database SQL Language Reference. 

There are some additional restrictions for using direct-path 
INSERT, These are listed in the Oracle Database SQL Language 
Reference. 



See Also: Oracle Database Performance Tuning Guide for more 
information on using hints 

How Direct-Path INSERT Works 

You can use direct-path INSERT on both partitioned and non-partitioned tables. 

Serial Direct-Path INSERT into Partitioned or Non-partitioned Tables The single process inserts 
data bevond the current high water mark of the table segment or of each partition 
segment. (The high-water mark is the level at which blocks have never been formatted 
to receive data,) When a COMMIT runs, the high-water mark is updated to the new 
value, making the data visible to users. 

Parallel Direct-Path INSERT into Partitioned Tables This situation is analogous to serial 
direct-path INSERT, Each parallel execution server is assigned one or more partitions. 
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with no more than one process working on a single partition. Each parallel execution 
server inserts data beyond the current high-water mark of its assigned partition 
segment(s). When a COMMIT runs, the high-water mark of each partition segment is 
updated to its new value, making the data visible to users. 

Parallel Direct-Path INSERT into Non-partitioned Tables Each parallel execution server 
allocates a new temporary segment and inserts data into that temporary segment. 
When a COMMIT runs, the parallel execution coordinator merges the new temporary 
segments into the primary table segment, where it is visible to users. 

Specifying tlie Logging Mode for Direct-Patli INSERT 

Direct-path INSERT lets you choose whether to log redo and undo information during 
the insert operation. 

■ You can specify logging mode for a table, partition, index, or LOB storage at create 
time (in a CREATE statement) or subsequently (in an ALTER statement). 

■ If you do not specify either LOGGING or NOLOGGING at these times: 

- The logging attribute of a partition defaults to the logging attribute of its table, 

- The logging attribute of a table or index defaults to the logging attribute of the 
tablespace in which it resides. 

- The logging attribute of LOB storage defaults to LOGGING if you specify 
CACHE for LOB storage. If vou do not specify CACHE, then the logging 
attributes defaults to that of the tablespace in which the LOB values resides, 

■ You set the logging attribute of a tablespace in a CREATE TABLESPACE or ALTER 
TABLESPACE statements. 



Note: If the database or tablespace is in FORCE LOGGING mode, 
then direct path INSERT always logs, regardless of the logging 
setting. 



Direct-Path INSERT with Logging In this mode, Oracle Database performs full redo 
logging for instance and media recovery. If the database is in ARCHIVELOG mode, then 
you can archive redo logs to tape. If the database is in NOARCHIVELOG mode, then you 
can recover instance crashes but not disk failures, 

Direct-Path INSERT without Logging In this mode, Oracle Database inserts data without 
redo or undo logging, (Some minimal logging is done to mark new extents invalid, 
and data dictionary changes are always logged.) This mode improves performance. 
However, if you subsequently must perform media recovery, the extent invalidation 
records mark a range of blocks as logically corrupt, because no redo data was logged 
for them. Therefore, it is important that vou back up the data after such an insert 
operation. 

Additional Considerations for Direct-Path INSERT 

The following are some additional considerations when using direct-path INSERT, 

Index Maintenance with Direct-Path INSERT Oracle Database performs index maintenance 
at the end of direct-path INSERT operations on tables (partitioned or non-partitioned) 
that have indexes. This index maintenance is performed by the parallel execution 
servers for parallel direct-path INSERT or by the single process for serial direct-path 
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INSERT. You can avoid the performance impact of index maintenance by dropping 
the index before the INSERT operation and then rebuilding it afterward. 

Space Considerations with Direct-Path INSERT Direct-path insert requires more space 
than conventional- path INSERT. 

All serial direct-path INSERT operations, as weU as parallel direct-path INSERT into 
partitioned tables, insert data above the high-water mark of the affected segment. This 
requires some additional space. 

Parallel direct-path INSERT into non-partitioned tables requires even more space, 
because it creates a temporary segment for each degree of parallelism. If the 
non-partitioned table is not in a locally managed tablespace in automatic 
segment-space management mode, you can modify the values of the NEXT and 
PCTINCREASE storage parameter and MINIMUM EXTENT tablespace parameter to 
provide sufficient (but not excess) storage for the temporary segments. Choose \'alues 
for these parameters so that: 

■ The size of each extent is not too small (no less than 1 MB), This setting affects the 
total number of extents in the object, 

■ The size of each extent is not so large that the parallel INSERT results in wasted 
space on segments that are larger than necessary. 

After the direct-path INSERT operation is complete, you can reset these parameters to 
settings more appropriate for serial operations. 

Locking Considerations with Direct-Path INSERT During direct-path insert, the database 
obtains exclusive locks on the table (or on all partitions of a partitioned table). As a 
result, users carmot perform any concurrent insert, update, or delete operations on the 
table, and concurrent index creation and build operations are not permitted. 
Concurrent queries, however, are supported, but the quer}' will return onl}' the 
information before the insert operation. 

Automatically Collecting Statistics on Tables 

The PL /SQL package DBMS_STATS lets vou generate and manage statistics for 
cost-based optimization. You can use this package to gather, modify, view, export, 
import, and delete statistics. You can also use this package to identify or name 
statistics that have been gathered. 

Formerly, you enabled DBMS_STATS to automatically gather statistics for a table by 
specifying the MONITORING keyword in the CREATE (or ALTER) TABLE statement. 
Starting with Oracle Database 11^, the MONITORING and NOMONITORING keywords 
have been deprecated and statistics are collected automatically. If you do specify these 
keywords, they are ignored. 

Monitoring tracks the approximate number of INSERT, UPDATE, and DELETE 
operations for the table since the last time statistics were gathered. Information about 
how many rows are affected is maintained in the SGA, until periodically (about every 
three hours) SMON incorporates the data into the data dictionary. This data dictionary 
information is made visible through the 

DBA_TAB_MODIFICATIONS.ALL_TAB_MODI EI CATIONS, or 

USER_TAB_MODI EI CATIONS views. The database uses these views to identify tables 
with stale statistics. 

To disable monitoring of a table, set the STATISTICS_LEVEL initialization parameter 
to BASIC, Its default is TYPICAL, which enables automatic statistics collection. 
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Aiitoniiitic statistics collection and the DBMS_STATS package enable the optimizer to 
generate accurate execution plans. 



See Also: 



Oracle Database Reference for detailed information on the 

STATISTICS_LEVEL initialization parameter 

Oracle Database Pcrfornnince Tuning Guide for information on 
managing optimizer statistics 

Oracle Database PL/SQL Packages and Types Reference for 
inform.ation about using the DBMS_STATS package 

"About A utomated Maintenance Tasks" on page 24-1 for 
information on using the Scheduler to collect statistics 
automatically 



Altering Tables 



You alter a table using the ALTER TABLE statement. To alter a table, the table must be 
contained in your schema, or you must have either the ALTER object privilege for the 
table or theALTER ANY TABLE system privilege. 

Many of the usages of the ALTER TABLE statement are presented in the following 
sections: 

Reasons for Using the ALTER TABLE Statement 

Altering Physical Attributes of a Table 

Moving a Table to a New Segment or Tablespace 

Manually Allocating Storage for a Table 

Modifying an Existing Column Definition 

Adding Table Columns 

Renaming Table Columns 

Dropping Table Columns 

Placing a Table in Read-Only Mode 

Caution: Before altering a table, familiarize yourself with the 
consequences of doing so. The Oracle Database SQL Language 
Reference lists many of these consequences in the descriptions of the 

ALTER TABLE clauses. 

If a view, materialized view, trigger, domain index, function-based 
index, check constraint, function, procedure of package depends on 
a base table, the alteration of the base table or its columns can affect 
the dependent object. See "Managing Object Dependencies" on 
page 16-17 for information about how the database manages 
dependencies. 

Reasons for Using the ALTER TABLE Statement 

You can use the ALTER TABLE statement to perform any of the following actions that 
affect a table: 
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Modify physical characteristics (INITRANS or storage parameters) 

Move the table to a new segment or tablespace 

Explicitly allocate an extent or deallocate unused space 

Add, drop, or rename columns, or modify an existing column definition (datatj'pe, 
length, default value, NOT NULL integrity constraint, column expression (for 
virtual columns), and encryption properties.) 

Modifv the logging attributes of the table 

Modify the CACHE /NOCACHE attributes 

Add, modify or drop integrity constraints associated with the table 

Enable or disable integritv constraints or triggers associated with the table 

Modify the degree of parallelism for the table 

Rename a table 

Put a table in read-onlv mode and return it to read/write mode 

Add or modify index -organized table characteristics 

Alter the characteristics of an external table 

Add or modifv LOB columns 

Add or modify object type, nested table, or varray columns 

Many of these operations are discussed in succeeding sections. 

Altering Physical Attributes of a Table 

When altering the transaction entry setting INITRAHS of a table, note that a new 

setting for INITRANS applies onlv to data blocks subsequentlv allocated for the table. 
To better understand this transaction entr\' setting parameter, see "Specifying the 
INITRANS Parameter" on page 17-4. 

The storage parameters INITIAL and MINEXTENTS cannot be altered. All new 
settings for the other storage parameters (for example, NEXT, PCTINCREASE) affect 
onlv extents subsequentlv allocated for the table. The size of the next extent allocated 
is determined by the current values of NEXT and PCTINCREASE, and is not based on 
previous values of these parameters. Storage parameters are discussed in "Managing 
Storage Parameters" on page 17-5, 

l\/loving a Table to a New Segment or Tablespace 

The ALTER TABLE. . .MOVE statement enables you to relocate data of a 
no n- partitioned table or of a partition of a partitioned table into a new segment, and 
optionallv into a different tablespace for which you have quota. This statement also 
lets vou modifv anv of the storage attributes of the table or partition, including those 
which cannot be modified using ALTER TABLE. You can also use the ALTER 
TABLE . . .MOVE statement with a COMPRESS clause to store the new segment using 
table compression. 

One important reason to move a table to a new tablespace (with a new datafile) is to 
eliminate the possibility that old versions of column data — versions left on now 
unused portions of the disk due to segment shrink, reorganization, or previous table 
moves — could be viewed bv bypassing the access controls of the database (for 
example with an operating system utility). This is especially important with columns 
that you intend to modify by adding transparent data encryption. 
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Note: TheALTER TABLE... MOVE statement does not permit DML 
against tlie table while the statement is executing. If vou want to leave 
the table available for DML while moving it, see "Redefining Tables 
Onhne" on page 18-26. 



The foilow^ing statement moves the hr . admin_enip table to a new segment, 
specifying new storage parameters: 

ALTER TABLE hr . admin_eiiii MOVE 
STORAGE ( IMITIAL 2 OK 
NEXT 4 OK 
MINEXTENTS 2 
MAXEXTENTS 2 
PCTIMCREASE ) ; 

Moving n table changes the rowids of the rows in the table. This causes indexes on the 
table to be marked UNUSABLE, and DML accessing the table using these indexes will 
receive an ORA-01502 error The indexes on the table must be dropped or rebuilt. 
Likewise, any statistics for the table become invalid and new statistics should be 
collected after moving the table. 

If the table includes LOB column(s), this statement can be used to move the table along 
with LOB data and LOB index segments (associated with this table) which the user 
explicitly specifies. If not specified, the default is to not move the LOB data and LOB 
index segments. 

See Also: "Consider Encrvp ting Columns That Contain Sensitive 
Data" on page 18-6 for more information on transparent data 
encryption 



Manually Allocating Storage for a Table 



Oracle Database dvnamicallv allocates additional extents for the data segment of a 
table, as required. However, perhaps you want to allocate an additional extent for a 
table explicitly. For example, in an Oracle Real Application Clusters environment, an 
extent of a table can be allocated explicitly for a specific instance. 

A new extent can be allocated for a table using the ALTER TABLE. . .ALLOCATE 
EXTENT clause. 

You can also explicitly deallocate unused space using the DEALLOCATE UNUSED 
clause of ALTER TABLE, This is described in "Reclaiming Wasted Space" on 
page 17-15, 

See Also: Oracle Real Application Chisicrs Adia in is f ration and 
Dcpioynicni Guide for information about using the ALLOCATE 
EXTENT clause in an Oracle Real Application Clusters environment 



Modifying an Existing Column Definition 



Use the ALTER TABLE . . .MODIFY statement to modify an existing column definition. 
You can modify column datatype, default value, column constraint, column 
expression (for virtual columns) and column encryption. 

You can increase the length of an existing column, or decrease it, if all existing data 
satisfies the new length. You can change a column from byte semantics to CHAR 
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sem.intics or vice versa. You must set the initialization parameter 
BLANK_TRIMMIWG=TRUE to decrease the length of a non-empty CHAR column. 

If you are modifying a table to increase the length of a column of datatype CHAR, 
realize that this can be a time consuming operation and can require substantial 
additional storage, especially if the table contains many rows. This is because the CHAR 
value in each row must be blank-padded to satisfy the new column length. 

See Also: Oracle Database SQL Language Reference for additional 
information about modifving table columns and additional 
restrictions 

Adding Table Columns 

To add a column to an existing table, use the ALTER TABLE . . .ADD statement. 

The following statement alters the hr . adinin_emp table to add a new column named 

ijonus: 

ALTER TABLE hr . adiniE._eiip 

ADD (bonus HUMBER (7,2}); 

If a new column is added to a table, the column is initially NULL unless you specify the 
DEFAULT clause. When you specify a default value, the database immediately updates 
each row with the default value. Note that this can take some time, and that during the 
update, there is an exclusive DML lock on the table. For some types of tables (for 
example, tables without LOB columns), if vou specify both a WOT NULL constraint and 
a default value, the database can optimize the column add operation and greatly 
reduce the amount of time that the table is locked for DML, 

You can add a column with a WOT NULL constraint only if the table does not contain 
any rows, or you specify a default value. 

See Also: Oracle Database SQL Language Reference for additional 
rules and restrictions for adding table columns 

Adding a Column to a Compressed Table 

If vou enable compression for all operations on a table, you can add columns to that 
table with or without default values. If you enable compression for direct-path inserts 
only, you can add columns only if vou do not specify default values. 

See Also: "Consider Using Table Compression" on page 18-5 

Adding a Virtual Column 

If the new column is a virtual column, its value is determined bv its column 
expression, (Note that a virtual column's value is calculated only when it is queried,) 



Renaming Table Columns 



Oracle Database lets vou rename existing columns in a table. Use the RENAME 
COLUMN clause of the ALTER TABLE statement to rename a column. The new name 
must not conflict with the name of anv existing column in the table. No other clauses 
are allowed in conjunction with the RENAME COLUMN clause. 

The following statement renames the comm column of the hr . admin_emp table, 

ALTER TABLE hr .adinin_e!np 

RENAME COLUMN comm TO commission; 
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As noted earlier, altering a table column can invalidate dependent objects. However, 
when you rename a column, the database updates associated data dictionary tables to 
ensure that function-based indexes and check constraints remain valid. 

Oracle Database also lets vou rename column constraints. This is discussed in 
"Renaming Constraints" on page 16-13, 



Note: The RENAME TO clause of ALTER TABLE appears similar in 
syntax to the RENAME COLUMN clause, but is used for renaming the 
table itself. 



Dropping Table Columns 



You can drop columns that are no longer needed from a table, including an 
index-organized table. This provides a convenient means to free space in a database, 
and avoids vour having to export/ import data then re-create indexes and constraints. 

You cannot drop all columns from a table, nor can vou drop columns from a table 
owned by SYS, Any attempt to do so results in an error. 

See Also: Oracle Database SQL Language Rejerence for information 
about additional restrictions and options for dropping columns 
from a table 

Removing Columns from Tables 

When 3'ou issue an ALTER TABLE . . . DROP COLUMN statement, the column 
descriptor and the data associated with the target column are removed from each row 
in the table. You can drop multiple columns with one statement. 

The follow^ing statements are examples of dropping columns from the hr . a.d.niin_enip 
table. The first statement drops only the sal column: 

ALTER TABLE hr . admin_sinp DROP COLUMN sal; 

The next statement drops both the bonus and comm columns: 
ALTER TABLE hr . admin_enip DROP (bonus, commission); 

Marking Columns Unused 

If vou are concerned about the length of time it could take to drop column data from 
allof the rows in a large table, you can use the ALTER TABLE. . .SET UWUSED 
statement This statement marks one or more columns as unused, but does not 
actuallv remove the target column data or restore the disk space occupied by these 
columns. However, a column that is marked as unused is not displaved in queries or 
data dictionarv views, and its name is removed so that a new column can reuse that 
name. All constraints, indexes, and statistics defined on the column are also removed. 

To mark thehiredate andmgr columns as unused, execute the following statement: 

ALTER TABLE hr . adiiiin_eiii> SET UNUSED (hiredate, mgr) ; 

You can later remove columns that are marked as unused bv issuing an ALTER 
TABLE . . . DROP UNUSED COLUMNS statement Unused columns are also removed 
from the target table whenever an explicit drop of anv particular column or columns 
of the table is issued. 
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The data dictionary views USER_UNUSED_COL_TABS, ALL_UNUSED_COL_TABS, or 
DBA_UMUSED_COL_TABS can be used to list all tables containing unused colunans. The 
COUNT field shows the number of unused columns in the table. 

SEIECT ' FROM DBA_UmiSED_C0L_TaB3 ; 

CMHER TABLE_NaME COUHT 

HK ADMIH.EMP 3 

For external tables, the SET UNUSED statement is transparently converted into an 
ALTER TABLE DROP COLUMN statement Because external tables consist of metadata 
onlv in the database, the DROP COLUMN statement performs equivalently to the SET 
UNUSED statement 

Removing Unused Columns 

TheALTER TABLE. ..DROP UNUSED COLUMNS statement is the only action allowed 
on unused columns. It physically removes unused columns from the table and 
reclaims disk space. 

In the ALTER TABLE statement that follows, the optional clause CHECKPOINT is 
specified. This clause causes a checkpoint to be applied after processing the specified 
number of rows, in this case 250. Checkpointing cuts down on the amount of undo 
logs accumulated during the drop column operation to avoid a potential exhaustion of 
undo space. 

ALTER TABLE hr . admin.enip DROP HMOSED COLUMNS CHECKPOINT 250; 

Dropping Columns in Compressed Tabies 

If vou enable compression for all operations on a table, vou can drop table columns. If 
you enable compression for direct-path inserts only, you cannot drop columns. 

See Also: "Consider Using Table Compression" on page 18-5 



Placing a Table in Read-Only Mode 



You can place a table in read-only mode with the ALTER TABLE., .READ ONLY 
statement, and return it to read/write mode with the ALTER TABLE. ..READ WRITE 
statement An example of a table for which read-only mode makes sense is a 
configuration table. If vour application contains configuration tables that are not 
modified after installation and that must not be modified bv users, your application 
installation scripts can place these tables in read-only mode. 

To place a table in read-only mode, you must have the ALTER TABLE privilege on the 
table or the ALTER ANY TABLE privilege. In addition, the COMPATIBILE initialization 
parameter must be set to 11.1.0 or greater. 

The following example places the SALES table in read-only mode: 

ALTER TABLE SALES READ ONLY; 

The following example returns the table to read/write mode: 

ALTER TABLE SALES READ WRITE; 

When a table is in read-only mode, operations that attempt to modify table data are 
disallowed. The following operations are not permitted on a read-only table: 

■ All DML operations on the table or any of its partitions 
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TRUNCATE TABLE 

SELECT FOR UPDATE 

ALTER TABLE ADD /MODIFY/REWAME /DROP COLUMN 

ALTER TABLE SET COLUMN UNUSED 

ALTER TABLE DROP/TRUNCATE/EXCHANGE ( SUB) PARTITION 

ALTER TABLE UPGRADE INCLUDING DATA or ALTER TYPE CASCADE INCLUDING 

TABLE DATA for a type with read-onlv table dependents 
Online redefinition 

FLASHBACK TABLE 

The following operations are permitted on a read-only table: 

SELECT 

create/alter/drop index 

ALTER TABLE ADD/MODIFY/DROP/ENABLE/DISABLE CONSTRAINT 

ALTER TABLE for physical property changes 

ALTER TABLE DROP UNUSED COLUMNS 

ALTER TABLE ADD/COALESCE/MERGE/MODIFY/MOVE/RENAME/SPLIT 
(SUB) PARTITION 

ALTER TABLE MOVE 

ALTER TABLE ENABLE ROW MOVEMENT and ALTER TABLE SHRINK 

RENAME TABLE and ALTER TABLE RENAME TO 

DROP TABLE 

ALTER TABLE DEALLOCATE UNUSED 

ALTER TABLE ADD/DROP SUPPLEMENTAL LOG 

See Also: Oracle Database SQL Language Reference for more 
information about the ALTER TABLE statement 
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In any database system, it is occasionally necessary to modify the logical or physical 
structure of a table to: 

■ Improve the performance of queries or DML 

■ Accommodate application changes 

■ Manage storage 

Oracle Database provides a mechanism to make table structure modifications without 
significantly affecting the availability of the table. The mechanism is called online 
table redefinition. Redefining tables online provides a substantial increase in 
availability compared to traditional methods of redefining tables. 

When a table is redefined online, it is accessible to both queries and DML during much 
of the redefinition process. The table is locked in the exclusive mode only during a 
very small window that is independent of the size of the table and complexity of the 
redefinition, and that is completely transparent to users. 
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Online t.ible redefinition requires an amount of free space that is approximately 
equivalent to the space used by the table being redefined. More space may be required 
if new columns are added. 

You can perform online table redefinition with the Enterprise Manager Reorganize 
Objects wizard or with the DBMS_REDEFIWITIOW package. 

Note: To invoke the Reorganize Objects wizard: 

1. On the Tables page of Enterprise Manager, click in the Select column to 

select the table to redefine. 

2. In the Actions list, select Reorganize. 

3. Chck Go. 

This section describes online redefinition with theDBMS_REDEFINITIOW package. It 
contains the following topics: 

Features of Online Table Redefinition 

Performing Online Redefinition with DBMS_RE DEFINITION 

Results of the Redefinition Process 

Performing Intermediate Synctironization 

Aborting Online Table Redefinition and Cleaning Up After Errors 

Restrictions for Online Redefinition of Tables 

Online Redefinition of a Single Partition 

Online Table Redefinition Examples 

Privileges Required for the DBMS_RE DEFINITION Package 

See Also: Oracle Database PL/SQL Packages and Types Reference for 
a description of the DBMS_REDEFINITION package 

Features of Online Table Redefinition 

Online table redefinition enables you to: 

■ Modify the storage parameters of a table or cluster 

■ Move a table or cluster to a different tablespace 

Note: If it is not important to keep a table available for DML w^hen 
moving it to another tablespace, vou can use the simpler ALTER 
TABLE MOVE command. See "Moving a Table to a New Segment or 
Tablespace" on page 18-21. 

■ Add, modify, or drop one or more columns in a table or cluster 

■ Add or drop partitioning support (non-clustered tables only) 

■ Change partition structure 

■ Change physical properties of a single table partition, including moving it to a 
different tablespace in the same schema 
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Change physical properties of a materialized view log or an Oracle Streams 
Advanced. Queueing queue table 



Add support for parallel queries 

Re-create a table or cluster to reduce fragmentation 



Note: In mnnv cases, online segment shrink is an easier wav to 
reduce fragmentation. See "Reclaiming Wasted Space" on page 17-15. 

■ Change the organization of a normal table (heap organized) to an index- organized 
table, or do the reverse. 

■ Convert a relational table into a table with object columns, or do the reverse. 

■ Convert an object table into a relational table or a table with object columns, or do 
the reverse. 

Performing Online Redefinition with DBIUIS.REDEFINITION 

You use the DBMS_REDEFIWITIOW package to perform online redefinition of a table. 
See Oracle Database PL/SQL Packages and Types Reference for package details. 

To redefine a table online: 

1. Choose the redefinition method: by key or hv rowid 

By key — Select a primary key or pseudo-primary kev to use for the redefinition. 
Pseudo-primar}" kevs are unique keys with all component columns having WOT 
NULL constraints. For this method, the versions of the tables before and after 
Tedefinition should have the same primary kev columns. This is the preferred and 
default method of redefinition. 

By rowid — Use this method if no key is available. In this method, a hidden 
column named M_ROWS S is added to the post-redefined version of the table. It is 
recommended that this column be dropped or marked as unused after the 
redefinition is complete. If COMPATIBLE is set to 10,2,0 or higher, the final phase 
of redefinition automatically sets this column unused. You can then use the ALTER 
TABLE ,,, DROP UNUSED COLUMNS statement to drop it. 

You cannot use this method on index- organized tables, 

2. Verify that the table can be redefined online bv invoking the CAN_REDEF_TABLE 
procedure. If the table is not a candidate for online redefinition, then this 
procedure raises an error indicating why the table cannot be redefined online, 

3. Create an empt}' interim table (in the same schema as the table to be redefined) 
with all of the desired logical and physical attributes. If columns are to be 
dropped, do not include them in the definition of the interim table. If a column is 
to he added, then add the column definition to the interim table. If a column is to 
be modified, create it in the interim table with the properties that vou want. 

It is not necessary to create the interim table with all the indexes, constraints, 
grants, and triggers of the table being redefined, because these will be defined in 
step 6 when you copy dependent objects, 

4. (Optional) If you are redefining a large table and want to improve the 
performance of the next step by running it in parallel, issue the following 
statements: 

alter session force parallel dml parallel degree-of-paralJelisro; 
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alter session force parallel query parallel degree -af-pard I leJ ism; 

5. Start the redefinition process hy ciilling STAET_EEDEF_TABLE, providing the 
following: 

■ The schema and table name of the table to be redefined 

■ The interim table name 

■ A column mapping string that maps the columns of table to be redefined to 
the columns of the interim table 

See "Constructing a Column Mapping String" on page 18-30 for details. 

■ The redefinition method 

Package constants are provided for specifying the redefinition method. 
DBMS_EEDEFIWITIOW.COWS_USE_PK is used to indicate that the redefinition 
should be done using primary keys or pseudo-primary keys. 
DBMS_EEDEFIWITIOW.COWS_USE_EOWID is use to indicate that the 
redefinition should be done using rowids. If this argument is omitted, the 
default method of redefinition (COWS_USE_PK) is assumed, 

■ Optionally, the columns to be used in ordering rows 

■ If redefining only a single partition of a partitioned table, the partition name 

Because this process involves copying data, it may take a while. The table being 
redefined remains available for queries and DML during the entire process. 

Note: If STAItT_REDEF_TaBLE fails for any reason, you must call 
ABOET_EEDEF_TABLE, otherwise subsequent attempts to redefine the 
table will fail. 



6. Copv dependent objects (such as triggers, indexes, materialized view logs, grants, 
and constraints) and statistics from the table being redefined to the interim table, 
using one of the following two methods. Method 1 is the preferred method 
because it is more automatic, but there mav be times that you would choose to use 
method 2. Method 1 also enables you to copy table statistics to the interim table. 

■ Method 1: Automatically Creating Dependent Objects 

Use the COPY_TABLE_DEPENriENTS procedure to automatically create 
dependent objects on the interim table. This procedure also registers the 
dependent objects. Registering the dependent objects enables the identities of 
these objects and their copied counterparts to be automaticallv swapped later 
as part of the redefinition completion process. The result is that when the 
redefinition is completed, the names of the dependent objects will be the same 
as the nanies of the original dependent objects. 

For more information, see "Creating Dependent Objects Automaticallv" on 
page 18-31, 

■ Method 2: Manually Creating Dependent Objects 

You can manuallv create dependent objects on the interim table and then 
register them. For more information, see "Creating Dependent Objects 
Manually" on page 18-31, 
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Note: In Oracle Database Release 9i, you were requiycd to 
manually create ttie triggers, indexes, grants, and constraints on the 
interini table, and there mav stiU be situations where you want to 
or must do so. In such cases, anv referential constraints involving 
the interim table (that is, the interim table is either a parent or a 
child table of the referential constraint) must be created disabled. 
When online redefinition completes, the referential constraint is 
automatically enabled. In addition, until the redefinition process is 
either completed or aborted, any trigger defined on the interim 
table does not execute. 



7. Execute the FINISH_REDEF_TABLE procedure to complete the redefinition of the 
table. During this procedure, the original table is locked in exclusive mode for a 
very short time, independent of the amount of data in the original table. However, 
FINI SH_HEDEF_TABLE will wait for all pending DML to commit before 
completing the redefinition. 

8. If vou used rowids for the redefinition and your COMPATIBLE initialization 
parameter is set to 10.1,0 or lower, drop or set UNUSED the hidden column 
M_ROWS S that is now in the redefined table. 

ALTER TABLE tdble_ndme SET UMUSED (M_R01$S); 

If COMPATIBLE is 10.2.0 or higher, this hidden column is automatically set 
UNUSED when redefinition completes. You can then drop the column with the 

ALTER TABLE ... DROP UNUSED COLUMNS statement. 

9. Wait for an\' long-running queries against the interim table to complete, and then 
drop the interim table. 

If vou drop the interim table while there are active queries running against it, vou 
may encounter an ORA-0 810 3 error ("object no longer exists"). 

See Also: "Online Table Redefinition Examples" on page 18-36 

Constructing a Column Mapping String 

The column mapping string that vou pass as an argument to START_REDEF_TABLE 
contains a com ma- separated list of column mapping pairs, where each pair has the 
following syntax: 

[ express! on] col uimi_name 

The column_name term indicates a column in the interim table. The optional 
expression can include columns from the table being redefined, constants, 
operators, function or method calls, and so on, in accordance with the rules for 
expressions in a SQL SELECT statement. How^ever, oniv simple deterministic 
subexpressions — that is, subexpressions whose results do not vary between one 
evaluation and the next — plus sequences and SYSDATE can be used. No subqueries 
are permitted. In the simplest case, the expression consists of just a column name from 
the table being redefined. 

If an expression is present, its value is placed in the designated interim table column 
during redefinition. If the expression is omitted, it is assumed that both the table being 
redefined and the interim table have a column named col umn_name, and the value of 
that column in the table being redefined is placed in the same column in the interim 
table. 
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For example, if the override column in the table being redefined is to be renamed to 
□verride_commission, and every override commission is to be raised by 2%, the 
correct column mapping pair is: 

override* 1.0 2 overrid.e_commiEEion 

If vou supply '*' or NULL as the column mapping string, it is assumed that ali the 
columns (with their names unchanged) are to be included in the interim table. 
Otherwise, oniy those columns specified explicitly in the string are considered. The 
order of the column mapping pairs is unimportant. 

For examples of column mapping strings, see "Online Table Redefinition Examples" on 
page 18-36, 

Data Conversions When mapping columns, you can convert data t\'pes, with some 
restrictions. 

If vou provide '*' or NULL as the column mapping string, oniy the implicit conversions 
permitted by SQL are supported. For example, you can convert from CHAR to 
VAHCHAR2, from INTEGER to NUMBER, and SO on. 

If vou want to perform other data tvpe conversions, including converting from one 
object type to another or one collection type to another, you must provide a column 
mapping pair with an expression that performs the conversion. The expression can 
include the CAST function, built-in functions like TO_NUMBER, conversion functions 
that you create, and so on. 

Creating Dependent Objects Automatically 

You use the COPY_TABLE_DEPENI>ENTS procedure to automatically create dependent 
objects on the interim table. 

You can discover if errors occurred while copying dependent objects by checking the 

niun_error3 output argument. If the ignore_errors argument is set to TRUE, the 
COPY_TABLE_DE PENDENTS procedure continues copving dependent objects even if 
an error is encountered when creating an object. You can view these errors by 
querying the DBA_REDEFINITION_ERRORS view. 

Reasons for errors include: 

■ A lack of system resources 

■ A change in the logical structure of the table that would require recoding the 
dependent object. 

See Example 3 in "Online Table Redefinition Examples" on page 18-36 for a 
discussion of this tvpe of error. 

If ignore_errorE is set to FALSE, the COPY_TABLE_DEPENDENTS procedure stops 
copving objects as soon as any error is encountered. 

After you correct any errors you can again attempt to copy the dependent objects bv 
reexecuting theCOPY_TABLE_DEPENDENTS procedure. Optionally you can create the 
objects manually and then register them as explained in "Creating Dependent Objects 
Manually", The COPY_TABLE_DEPENDENTS procedure can be used multiple times as 
necessary. If an object has already been successfully copied, it is not copied again. 

Creating Dependent Objects Manualiy 

If vou manuallv create dependent objects on the interim table with SQL'Phis or 
Enterprise Manager, you must then use the REGI STER_DEPENDENT_OBJECT 
procedure to register the dependent objects. Registering dependent objects enables the 
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redefinition completion process to restore dependent object names to what they were 
before redefinition. 

You would also use the REGI STER_DEPENDENT_OBJECT procedure if the 
COPY_TABLE_DEPENDENTS procedure failed to copy a dependent object and manual 
intervention is required. 

You can query the DBA_REDEFIHITIOH_OBJECTg view to determine which 
dependent objects are registered. This view shows dependent objects that were 
registered explicitly with the REGI STER_DEPENDENT_OBJECT procedure or 
implicitly with the COPY_TABLE_DEPENDENTS procedure. Only current information 
is shown in the view. 

The UNREGISTER_DEPENDENT_OBJECT procedure can be used to unregister a 
dependent object on the table being redefined and on the interim table. 

Note: Manually created dependent objects do not ha\'e to be 
identical to their corresponding original dependent objects. For 
example, when manuallv creating a materialized view log on the 
interim table, you can log different columns. In addition, the interim 
table can have more or fewer dependent objects. 

Results of the Redefinition Process 

The following are the end results of the redefinition process: 

■ The original table is redefined with the columns, indexes, constraints, grants, 
triggers, and statistics of the interim table, 

■ Dependent objects that were registered, either explicitly using 

REGISTER_DEPENDENT_OBJECT or implicitly using COPY_TABLE_DE PENDENTS, 

are renamed automaticallv so that dependent object names on the redefined table 
are the same as before redefinition. 



Note: If no registration is done or no automatic copving is done, 
then you must manually rename the dependent objects. 



The referential constraints involving the interim table now invoh'e the redefined 
table and are enabled. 

Any indexes, triggers, materialized view logs, grants, and constraints defined on 
the original table (prior to redefinition) are transferred to the interim table and are 
dropped when the user drops the interim table. Any referential constraints 
involving the original table before the redefinition now involve the interim table 
and are disabled. 

Some PL/SQL objects that depend on the original table (prior to redefinition) mav 
become invalidated. Only those objects that depend on elements of the table that 
were changed are invalidated. For example, if a PL/SQL procedure queries only 
columns of the redefined table that were unchanged bv the redefinition, the 
procedure remains valid. See Orack Database Concepts for more information about 
schema object dependencies. 



Performing Intermediate Synchronization 



After the redefinition process has been started by caUing START_REDEF_TABLE and 
before FINISH_REDEF_TABLE has been called, it is possible that a large number of 
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DML statements have been executed on the original table. If you know that this is the 
case, it is recommended that vou periodically synchronize the interim table with the 
original table. This is done by calUng the SYNC_INTERIM_TABLE procedure. Calling 
this procedure reduces the time taken by FIHISH_REDEF_TABLE to complete the 
redefinition process. There is no limit to the number of times that you can call 

S YNC_I NT ERIM_TABL E . 

The small amount of time that the original table is locked during 

FIWI SH_REDEF_TABLE is independent of whether SYNC_INTERIM_TABLE has been 

called. 

Aborting Online Table Redefinition and Cleaning Up After Errors 

In the event that an error is raised during the redefinition process, or if you choose to 
terminate the redefinition process, call ABORT_REDEF_TABLE. This procedure drops 
temporarv logs and tables associated with the redefinition process. After this 
procedure is called, you can drop the interim table and its dependent objects. 

If the online redefinition process must be restarted, if you do not first call 
ABORT_REDEF_TABLE, subsequent attempts to redefine the table will fail. 

RestrictJonsfor Online Redefinition of Tables 

The following restrictions apply to the online redefinition of tables: 

■ If the table is to be redefined using primary key or pseudo-primary kevs (unique 
keys or constraints with all component columns having not mil! constraints), then 
the post- redefinition table must have the same primary key or pseudo-primary 
key columns. If the table is to be redefined using rowids, then the table must not 
be an index -organized table. 

■ After redefining a table that has a materialized view log, the subsequent refresh of 
any dependent materialized view must be a complete refresh. 

■ Tables that are replicated in an n-way master configuration can be redefined, but 
horizontal subsetting (subset of rows in the table), vertical subsetting (subset of 
columns in the table), and column transformations are not allowed. 

■ The overflow table of an index -organized table cannot be redefined online 
independently. 

■ Tables with fine-grained access control (row-level security) cannot be redefined 
online. 

■ Tables with BFILE columns cannot be redefined online, 

■ Tables with LONG columns can be redefined online, but those columns must be 
converted to CLOBS, Also, LONG RAW columns must be converted to BLOBS, 
Tables with LOB columns are acceptable. 

■ On a system with sufficient resources for parallel execution, and in the case where 
the interim table is not partitioned, redefinition of a LONG column to a LOB column 
can be executed in parallel, provided that; 

— The segment used to store the LOB column in the interim table belongs to a 
locallv managed tablespace with Automatic Segment Space Management 
(ASSM) enabled. 

— There is a simple mapping from one LONG column to one LOB column, and the 
interim table has onlv one LOB column. 
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In the case where the interim table is partitioned, the normal methods for parallel 
execution for partitioning apply. 

Tables in the SYS and SYSTEM schema cannot be redefined online. 

Temporar}' tables cannot be redefined. 

A subset of rows in the table cannot be redefined. 

Only simple deterministic expressions, sequences, and SYSDATE can be used 
when mapping the columns in the interim table to those of the original table. For 
example, subqueries are not allowed. 

If new columns are being added as part of the redefinition and there are no 
column mappings for these columns, then they must not be declared NOT NULL 
until the redefinition is complete. 

There cannot be anv referential constraints between the table being redefined and 
the interim table. 

Table redefinition cannot be done NOLOGGING, 

For materialized view logs and queue tables, online redefinition is restricted to 
changes in physical properties. No horizontal or vertical subsetting is permitted, 
nor are any column transformations. The only valid value for the column mapping 
string is NULL, 

You can convert a VARRAY to a nested table with the CAST operator in the column 
mapping. However, vou cannot convert a nested table to a VARRAY, 



Online Redefinition of a Single Partition 



Beginning with Oracle Database lOg Release 2, you can redefine online a single 
partition of a table. This is useful if, for example, you want to move a partition to a 
different tablespace and keep the partition available for DML during the operation. 

Another use for this capability is redefining an entire table, but doing it one partition 
at a time to reduce resource requirements. For example, if vou want to move a very 
large table to a different tablespace, vou can move it one partition at a time to 
minimize the free space and undo space required to complete the move. Be aware, 
however, that when vou redefine a single partition, if a global index is present, it is 
marked as UNUSABLE when redefinition is complete. 

Redefining a single partition differs from redefining a table in the following ways: 

■ There is no need to copy dependent objects. It is not valid to use the 
COPY_TABLE_DEPENDENTS procedure when redefining a single partition, 

■ You must manually create any local indexes on the interim table, 

■ The column mapping string for START_REDEF_TABLE must be NULL, 

■ When using the by-rowid method, the final phase of redefinition drops the hidden 
column M_ROWS $ instead of setting it unused. 
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Note: If it is not important to keep a partition available for DML 
when moving it to another tablespace, you can use the simpler ALTER 
TABLE MOVE PARTITION command. 

See also: 

■ The section "Moving Partitions" in Oracle Database VLDB and 
Partitioning Guide 

■ Oracle Database SQL Language Reference 

Rules for Online Redefinition of a Single Partition 

The underlying mechanism for redefinition of a single partition is the exchange 
partition capability of the database (ALTER TABLE... EXCHANGE PARTITION). Rules 
and restrictions for online redefinition of a single partition are therefore governed by 
this mechanism. Here are some general restrictions: 

■ No logical changes (such as adding or dropping a column) are permitted. 

■ No changes to the partitioning method (such as changing from range partitioning 
to hash partitioning) are permitted. 

■ If a global index is present, it is marked as UNUSABLE when redefinition of anv 
table partition is complete. 

Here are the rules for defining the interim table: 

■ If the partition being redefined is a range, hash, or list partition, the interim table 
must be n on- partitioned. 

■ If the partition being redefined is a range partition of a composite range-hash 
partitioned table, the interim table must be a hash partitioned table. In addition, 
the partitioning key of the interim table must be identical to the sub partitioning 
key of the range-hash partitioned table, and the number of partitions in the 
interim table must be identical to the number of subpartitions in the range 
partition being redefined. 

■ If the partition being redefined is a range partition of a composite range-list 
partitioned table, the interim table must be a list partitioned table. In addition, the 
partitioning kev of the interim table must be identical to the subpartitioning key of 
the range-list partitioned table, and the values lists of the interim table's list 
partitions must exactly match the values lists of the list subpartitions in the range 
partition being redefined. 

■ If vou define the interim table as compressed, you must do one of the following: 

- Use the by-key method of redefinition, not the by-rowid method. 

- If the row-id method is unavoidable, define the interim table as COMPRESS 

FOR ALL OPERATIONS. 

These additional rules apply if the table being redefined is a partitioned 
index -organized table: 

■ The interim table must also be index- organized. 

■ The original and interim tables must have primarv keys on the same columns, in 
the same order. 

■ If key compression is enabled, it must be enabled for both the original and interim 
tables, with the same prefix length. 
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Both the original and interim tables must have overflow segments, or neither can 
have them. Likewise for mapping tables. 

Both the original and interim tables must have identical storage attributes for any 
LOB columns. 

See Also: The section "Exchanging Partitions" in Oracle Database 
VLDB and ParfiSioiiiirg Guide 



Online Table Redefinition Examples 



For the following examples, see Oracle Database PL/SQL Packages and Types Reference for 
descriptions of all DBMS_REDEFINITIOISI subprograms. 

Example Description 

Ex.imple 1 Redefines a tiible by adding new columns and adding partitioning. 

Example 2 Demonstrates redefinition with object datatypes. 

Example 3 Demonstrates redefinition with manually registered dependent objects 

Example 4 Redefines a single table partition, moving it to a different tablespace. 

Example 1 

This example illustrates online redefinition of the previously created table 

hr . admin_emp, which at this point only contains columns: empno, ename, j ob, 
deptno. The table is redefined as follows: 

■ New columns mgr, hiredate, sal, and bonus are added, (These existed in the 
original table but were dropped in previous examples.) 

■ The new column bonus is initialized to 

■ ThecoliLmn deptno has its value increased by 10. 

■ The redefined table is partitioned bv range on empno. 
The steps in this redefinition are illustrated below, 

1. Verify that the table is a candidate for online redefinition. In this case voil specify 
that the redefinition is to be done using primary keys or pseudo-prim a rv keys, 

BEGIH 

DBMS_HEDEFINITIOH , CM_REDEF_TABLE ( ' hr ' , ' adinin_emp ' , 

DBMS_REDEFIHITIOH,COHS_USE_PK) ; 
END; 
/ 

2. Create an interim table hr . int_adniin_einp, 

CREATE TftBLE hr . int_admin_eiiip 

{empno HUHBER(5} PRIMftHY KEY, 

ename VARCHAR2(15) NOT MULL, 

job VARCHAR2(10) , 

mgr lUMBER ( 5 } , 

hiredate DATE DEFAULT (sysdate) , 
aal HUMBER(7,2) , 

deptno HUMBER(3} NOT NULL, 

bonus HUMBER (7,2) DEFAULT (IDOO) ) 

PARTITION BY RMGE{empno) 

(PARTITION einplOOO VALUES LESS THAN (1000) TABLESPACE adniin_tbs, 
PARTITION erap2000 VALUES LESS THAN (2000) TABLESPACE adniin_tbs2] ; 
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3. Start the redefinition process. 

BEGIH 

DBMS_REDEFINITIOH . START_REDEF_TABLE { ' hr ' , ' admin_emp ' , ' int_adinin_emp ' , 

' empno empno, ename enaine, job job, dept:no+10 deptno, bonus'. 
dbraE_redef iiiition.conE_"UEe_pk) ; 
END; 
/ 

4. Copy dependent objects. (Automatically create any triggers, indexes, materialized 
view logs, grants, and constraints on hr . int_admin_emp,) 

DECLME 

mmi.errors PL3_IHTEGER; 

BEGIM 

DBMS_REDEFINITIOH . COF¥_TABI£_DEPENDENTS ( ' hr ' , ' admiri_emp ' , ' int_adiiLin_erap ' , 

DBMS_EEDEFINITI0H.C0H3_0EIG_PARfflS, TRUE, TRUE, TRUE, TRUE, riuiiL_errors) ; 
END; 

Note that the ignore_error s argument is set to TRUE for this call. The reason is 
that the interim table was created with a primary kev constraint, and when 
COPY_TABLE_DEPENDENTS attempts to copy the primary key constraint and 
index from the original table, errors occurs. You can ignore these errors, but you 
must run the query shown in the next step to see if there are other errors, 

5. Quer}' the DBA_REDEFINITION_ERRORS view to check for errors, 

SQL> select ob j ec t_naiiie , base_table_name, ddl_t:xt from 
DBA_REDEFIHITION_ERRORS ; 

OBJECT_HME BASE_TABI£_HME DDL_TXT 

SY3_C005836 ADMIH_EMP CREftTE UNIQUE IHDEX "HRVTMPS 

5_SYS_C0058350" OH "HR","IHT_A 
DMIH_EMP" ("EMPHO") 

SYS_C005836 ADMIN.EMP ALTER TABLE "HR" , "INT_ADMIH_EH 

P" ADD COHSTRAIHT "TMP5S_SYS_C 
0058360" PRIMARY KEY 

These errors are caused by the existing primary kev constraint on the interim table 
and can be ignored. Note that with this approach, the names of the primary key 
constraint and index on the post-redefined table are changed. An alternate 
approach, one that avoids errors and name changes, would be to define the 
interim table without a primar}' key constraint In this case, the primar}' key 
constraint and index are copied from the original table. 

Note: The best approach is to define the interim table with a primary 
key constraint, use REGI gTER_DEPEWDEWT_OBJECT to register the 
priman' key constraint and index, and then copy the remaining 
dependent objects with CO PY_TABLE_DE PENDENTS, This approach 
avoids errors and ensures that the redefined table always has a 
primary key and that the dependent object names do not change. 



6. Optionally, synchronize the interim table hr . int_admin_emp, 

BEGIN 

DBMS_REDEFIHITIOH , SYMC_INTERIM_TABLE ( ' hr ' , ' adinin_erap ' , ' int_adniin_einp ' ) ; 
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END; 
/ 

7. Complete the redefinition. 

BEGIH 

DBMS_HEDEFINITION.FIHISH_REDEF_TABLE( 'hr', ■adiniri_erap ' , ' int_adniin_emp ' ) ; 

EKD; 

/ 

The table hr . ad.min_emp is locked in the exclusive mode only for a small 
window toward the end of this step. After this call the table hr . ad.min_emp is 
redefined such that it has al! the attributes of the hr . int_admin_emp table. 

8. Wait for any long-running queries against the interim table to complete, and then 
drop the interim table. 

Example 2 

This example redefines a table to change columns into object attributes. The redefined 
table gets a new column that is an object type. 

The original table, named CUSTOMER, is defined as follows: 

Hame Type 



CID NUMBER <- Primary key 

HME VARCHAE2 (30} 

STREET VARCHAE2 (100) 

CITY VARCHAE2 (30} 

STATE VARCHAE2 (2) 

ZIP MUMBER{5) 

The type definition for the new object is: 

CREATE TYPE ADDR_T A3 OBJECT ( 
3t:reet VAECHftE2 (100) , 
city VARCHAR2{30) , 
state VARCHAR2(2) , 
zip m]MBER{5, 0) } ; 

Here are the steps for this redefinition: 

1 . Verify that the table is a candidate for online redefinition. Specify that the 
redefinition is to be done using primary kevs or pseudo-primary keys, 

BEGIN 

DBMS_HEDEFINITIOH , CAN_REDEF_TABLE ( ' STEVE ' , ' CUSTOMED ' , 

DBHS_HEDEFIHITION.COMS_USE_PK) ; 
END; 
/ 

2. Create the interim table int_customer, 

CREATE TABLE INT_CUSTOMER ( 
CID NUMBER, 
NAME VARCHAR2{30) , 
ADDR ADDR_T) ; 

Note that no primary key is defined on the interim table. When dependent objects 
are copied in step 5, the primary kev constraint and index are copied. 
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3. Because CUSTOMER is a very large table, specify paraUel operations for the next 
step, 

alter session force parallel dml parallel 4; 
alter session force parallel query parallel 4; 

4. Start the redefinition process using primary keys, 

BEGIH 

DBMS_HEDEFIHITIOH , START_REDEF_TABLE { 

imame => 'STEVE', 

orig_table => 'CUSTOMER', 

int_table => ' IMT_CUSTOMER' , 

col_mapping => 'cid cid, name name, 

addr_t {street, city, state, zip) addr'); 
END; 
/ 

Note that ad.dr_t (street, city, state, zip) is a call to the object 
constructor, 

5. Copy dependent objects, 

DECLAHB 

nniiL_errors PLS_IHTEGER; 

BEGIH 

DBMS_REDEFINITIOH , COF¥_TABI£_DEPEHDENTS ( 

' STEVE ■ , ' CUSTOMER ' , ' INT_CUSTOMER ' , DBMS_EEDEFI[JITIOH , COHS_OEIG_PARMS , 
TRUE, TRUE, TRUE, FALSE, nuin_errors, TRUE) ; 
END; 
/ 

Note that for this call, the final argument indicates that table statistics are to be 
copied to the interim table, 

6. Optionally synchronize the interim table, 

BEGIH 

DBMS_REDEFINITIOH , S¥HC_IHTERIM_TABLE ( ' STEVE ' , ' CUSTOMER ' , ' INT_CUSTCMER ' ) ; 

END; 

/ 

7. Complete the redefinition, 

BEGIH 

DBMS_REDEFIHITIOH , FIHISH_REDEF_TABLE ( ' STEVE ' , ' CUSTOMER ' , ' INT_CUSTCMER ' ) ; 

END; 

/ 

8. Wait for any long-running queries against the interim table to complete, and then 
drop the interim table. 

Example 3 

This example addresses the situation where a dependent object must be manually 
created and registered. 

Consider the case where a table Tl has a column named CI, and where this column 
becomes C2 after the redefinition. Assume that there is an index Indexl on CI, In this 
case, COPY_TABLE_DEPENDENTS tries to create an index on the interim table 
corresponding to Indexl, and tries to create it on a column CI, which does not exist 
on the interim table. This results in an error You must therefore manually create the 
index on column C 2 and register it. Here are the steps: 
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1. Create the interim table INT_T1 and create an index Int_Indexl on column C2, 

2. Ensure that Tl is a candidate for onhne redefinition with CAN_REDEF_TABLE, and 
then begin the redefinition process with START_REDEF_TABLE. 

3. Register the original (indexl) and interim (lnt_Indexl) dependent objects. 

BEGIN 

DBMS_REDEFINITIOH . REGISTER_DEPENDEHT_OBJECT ( 

luiarae => 'STEVE', 

orig_table => 'Tl' , 

int_taljle => ' INT_T1 ' , 

dep_type => DBHS_REDEFIHITIOH.COHS_INDEX, 

dep_owner => 'STEVE', 

dep_orig_naiiie => 'Indexl', 

dep_int_naine => ' Int_Indexl ' ) ; 
END; 
/ 

4. Use CO PY_TABLE_DE PENDENTS to copy the remaining dependent objects. 

5. Optionally synchronize the interim table. 

6. Complete the redefinition and drop the interim table. 

Example 4 

This example demonstrates redefining a single partition. It moves the oldest partition 
of a range- partitioned sales table to a tablespace named TBS_LOW_FREQ. The table 
containing the partition to be redefined is defined as follows; 

CPEATE TABLE salestable 

{s_productid NUMBER, 

s_saledate DATE, 

s_custid NUMBER, 

s_totalprice NUMBER) 

TABLESPACE users 

PARTITION BY RAHGE (s_saledate) 

{PARTITION sal03ql VALUES LESS THftH (TO_DATE ( ' Ol-APR-2003 ' , 'DD-MOH-YYYY' ) ) , 
PARTITION Eal03q2 VALUES LESS 'fflAK {TO_DATE( ' Ol-JUL-2003 ' , 'DD-MON-YYYY' ) ) , 
PARTITION Eal03q3 VALUES LESS 'fflAH {TO_DATE( ' Ol-OCT-2003 ' , 'DD-MON-YYYY')}, 
PARTITION Eal03q4 VALUES LESS 'fflAM {TO_DATE( ' Ol-JM-2004 ' , 'DD-MON-YYYY')}); 

The table has a local partitioned index that is defined as follows: 

CREATE INDEX sale3_index ON salestable 

[s_saledate, s_productid, s_custid) LOCAL; 

Here are the steps. In the following procedure calls, note the extra argument: partition 
name (part_name). 

1. Ensure that salestable is a candidate for redefinition, 

BEGIN 

DBMS_REDEFINITION . CAN_REDEF_TABLE ( 

imame => ' STEVE ' , 

tname => ' SALESTABLE ' , 

options_flag => DBMS_REDEFimTION.C0NS_USE_R0WID, 

part_nanie => 'sal03ql'}; 
END; 
/ 
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2. Create the mterim table m the TBS_LOW_FREQ tablespace. Because this is a 
redefinition of a range partition, the interim table is non- partitioned. 

CPEATE TftBLE irit_s ales table 
{s_productid MUMBER, 
s_3aledate DATE, 
s_custid NUMBER, 
s_totalprice NUMBER) 
TABLESPACE tbs_low_Ereq; 

3. Start the redefinition process using rowid. 

BEGIH 

DBMS_REDEFINITIOH . START_REDEF_TABLE { 

uname => ' STEVE ' , 

orig_table => ' salestable ' , 

iiit_table => ' irit_salestable' , 

col_mapping => HULL, 

option3_flag => DBMS_HEDEFINITIOH.C0NS_USE_E0WID, 

part_narne => '3al03ql'}; 
END; 
/ 

4. Manually create any local indexes on the interim table, 

CREATE IHDEX irit_saleE_index ON int_EaleEtable 
{s_Ealedate, s_productid, s_custid) 
TABLESPACE tbs_low_freq; 

5. Optionallv synchronize the interim table. 

BEGIH 

DBMS_REDEFINITIOH . S¥HC_INTERIM_TABLE ( 

uname => 'STEVE', 

orig_table => 'salestable', 

iiit_table => ' iiit_salestable ' , 

part_narne => 'sal03ql'); 
END; 
/ 

6. Complete the redefinition. 

BEGIH 

DBMS_REDEFINITIOH . FIHISH_REDEF_TABLE ( 

imame => 'STEVE', 

orig_table => 'salestable', 

int_table => ' int_salestable ' , 

part_naiiie => 'sal03ql'); 
END; 
/ 

7. Wait for any long-running queries against the interim table to complete, and then 
drop the interim table. 

The following querv shows that the oldest partition has been moved to the new 
tablespace: 

select partition_name, tables pa ce_narae from user_tab_partition3 
where table_naine = 'SALESTABLE'; 

PARTITIOH_NAME TABLES PACE_NftHE 

SAL03Q1 TBS_LOW_FREQ 
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SAL03Q2 DSEHS 

SM,03Q3 USERS 

SM,03Q4 USERS 

4 rows selected. 

Privileges Required for the DBI\/IS_REDEFINITION Pacltage 

Execute privileges on the DBMS_REDEFINITION package are granted to 
EXECUTE_CATALOG_ROLE. In addition to having execute privileges on this package, 
you must be granted the following privileges; 

CREATE ANY TABLE 
ALTER ANY TABLE 
DROP ANY TABLE 
LOCK ANY TABLE 
SELECT ANY TABLE 

The following additional privileges are required to execute 

C P Y_TABL E_DE P ENDENT S : 

■ CREATE ANY TRIGGER 

■ CREATE ANY INDEX 

Researching and Reversing Erroneous Table Changes 

To enable you to research and reverse erroneous changes to tables, Oracle Database 
provides a a group of features that you can use to view past states of database objects 
or to return database objects to a previous state without using point-in-time media 
recover;'. These features are known as Oracle Flashback features, and are described in 
Oracle Database Advanced Application Developer's Guide. 

To research an erroneous change, you can use multiple Oracle Flashback queries to 
view row data at specific points in time. A more efficient approach would be to use 
Oracle Flashback Version Quer;' to view all changes to a row over a period of time. 
With this feature, you append a VERSIONS clause to a SELECT statement that specifies 
a system change number (SCN) or timestamp range between which you want to view 
changes to row values. The querv also can return associated metadata, such as the 
transaction responsible for the change. 

After vou identifv an erroneous transaction, vou can use Oracle Flashback Transaction 
Querv to identify other changes that were made bv the transaction. You can then use 
Oracle Flashback Transaction to reverse the erroneous transaction. (Note that Oracle 
Flashback Transaction must also reverse all dependent transactions — subsequent 
transactions involving the same rows as the erroneous transaction.) You also have the 
option of using Oracle Flashback Table, described in "Recovering Tables Using Oracle 
Flashback Table" on page 18-43. 



Note: You must be using automatic undo management to use 
Oracle Flashback features. See Introduction to Automatic Undo 
Management" on page 14-2. 



See Also: Oracle Database Advanced Application Developer's Guide 
for iniormation about Oracle Flashback features. 
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Recovering Tables Using Oracle Flashback Table 

Oracle Flashback Table enables you to restore a table to its state as of a previous point 
in time. It provides a fast, online solution for recovering a table that has been 
accidentally modified or deleted by a user or application. In many cases, Oracle 
Flashback Table eliminates the need for vou to perform more complicated 
point-in-time recoven' operations. 

Oracle Flashback Table: 

■ Restores all data in a specified table to a previous point in time described bv a 
timestamp or SCN. 

■ Performs the restore operation online, 

■ Automatically m.aintains all of the table attributes, such as indexes, triggers, and 
constraints that are necessary for an application to function with the flashed-back 
table. 

■ Maintains anv remote state in a distributed environment. For example, all of the 
table modifications required bv replication if a replicated table is flashed back, 

■ Maintains data integritv as specified by constraints. Tables are flashed back 
provided none of the table constraints are violated. This includes any referential 
integritv constraints specified between a table included in the FLASHBACK TABLE 
statement and another table that is not included in the FLASHBACK TABLE 
statement, 

■ Even after a flashback operation, the data in the original table is not lost. You can 
later revert to the original state. 



Note: You must be using automatic undo management to use 
Oracle Flashback Table. See "Introduction to Automatic Undo 
Management" on page 14-2. 



See Also: Oracle Database Backup and Recovery User's Guide for 
more information about the FLASHBACK TABLE statement. 



Dropping Tables 



To drop a table thatyou no longer need, use the DROP TABLE statement. The table 
must be contained in your schema or you must have the DROP ANY TABLE system 
privilege. 



Managing Tables 18-43 



Using Flashback Drop and Managing the Recycle Bin 



Caution: Before dropping a table, familiarize yourself with the 
consequences of doing so: 

■ Dropping a table removes the table definition from the data 
dictionary. All rows of the table are no longer accessible. 

■ All indexes and triggers associated with a table are dropped. 

■ All views and PL/SQL program units dependent on a dropped 
table remain, yet become invalid (not usable). See "Managing 
Object Dependencies " on page 16-17 for information about how 
the database manages dependencies. 

■ AU synonyms for a dropped table remain, but return an error 
when used. 

■ All extents allocated for a table that is dropped are returned to 
the free space of the tablespace and can be used by anv other 
object requiring new extents or new objects. All rows 
corresponding to a clustered table are deleted from the blocks 
of the cluster Clustered tables are the subject of Chapter 20, 
"Managing Clusters". 

The following statement drops the hr . int_admin_emp table: 
DROP TABLE hr . int_admin_erap; 

If the table to be dropped contains anv primary or unique keys referenced bv foreign 
keys of other tables and vou intend to drop the FOREIGN KEY constraints of the child 
tables, then include the CASCADE clause in the DROP TABLE statement, as shown 
below: 

DROP TABLE hr . admin_emp CASCADE CONSTRAINTS; 

When you drop a table, normally the database does not immediately release the space 
associated with the table. Rather, the database renames the table and places it in a 
recycle bin, where it can later be recovered with the FLASHBACK TABLE statement if 
you find that vou dropped the table in error If you should want to immediately 
release the space associated with the table at the time you issue the DROP TABLE 
statement, include the PURGE clause as shown in the following statement: 

DROP TABLE hr . admin_emp PURGE; 

Perhaps instead of dropping a table, vou want to truncate it. The TRUNCATE statement 
provides a fast, efficient method for deleting all rows from a table, but it does not 
affect any structures associated with the table being truncated (column definitions, 
constraints, triggers, and so forth) or authorizations. The TRUNCATE statement is 
discussed in "Truncating Tables and Clusters" on page 16-6. 

Using Flashback Drop and Managing the Recycle Bin 

When you drop a table, the database does not immediatelv remove the space 
associated with the table. The database renames the table and places it and any 
associated objects in a recvcle bin, where, in case the table was dropped in error, it can 
be recovered at a later time. This feature is called Flashback Drop, and the FLASHBACK 
TABLE statement is used to restore the table. Before discussing the use of the 
FLASHBACK TABLE statement for this purpose, it is important to understand how the 
recycle bin works, and how you manage its contents, 
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This section contains the following topics: 

■ What Is the Recycle Bin? 

■ Viewing and Querying Objects in the Recycle Bin 

■ Purging Objects in the Recycle Bin 

■ Restoring Tables from the Recycle Bin 



What Isthe Recycle Bin? 



The recycle bin is actually a data dictionary table containing information about 
dropped objects. Dropped tables and any associated objects such as indexes, 
constraints, nested tables, and the likes are not removed and still occupy space. They 
continue to count against user space quotas, until specifically purged from the recycle 
bin or the unlikely situation where they must be purged bv the database because of 
tablespace space constraints. 

Each user can be thought of as haying his own recycle bin, since unless a user has the 
SYSDBA priyilege, the only objects that the user has access to in the recycle bin are 
those that the user owns. A user can view his objects in the recycle bin using the 
following statement: 

SELECT ' FROM RECYCLEBIM; 

When you drop a tablespace including its contents, the objects in the tablespace are 
not placed in the recycle bin and the database purges any entries in the recycle bin for 
objects located in the tablespace. The database also purges any recycle bin entries for 
objects in a tablespace when you drop the tablespace, not including contents, and the 
tablespace is otherwise empt}'. Likewise: 

■ When you drop a user, any objects belonging to the user are not placed in the 
recycle bin and anv objects in the recycle bin are purged, 

■ When you drop a cluster, its member tables are not placed in the recycle bin and 
any former member tables in the recycle bin are purged. 

■ When you drop a t\'pe, any dependent objects such as subt\'pes are not placed in 
the recycle bin and any former dependent objects in the recycle bin are purged. 

Object Naming in the Recycle Bin 

When a dropped table is moved to the recycle bin, the table and its associated objects 
are given system-generated names. This is necessary to avoid name conflicts that may 
arise if multiple tables haye the same name. This could occur under the following 
circumstances: 

■ A user drops a table, re-creates it with the same name, then drops it again. 

■ Two users have tables with the same name, and both users drop their tables. 
The renaming convention is as follows: 

BINS unig;je_idS version 

where: 

■ uniqus_id is a 26-character globally unique identifier for this object, which 
makes the recycle bin name unique across all databases 

■ version is a version number assigned by the database 
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Enabling and Disabling tfie Recycle Bin 

YoLL can enable and disable the recycle bin with the recyclebin initialization 
parameter. When the recycle bin is enabled, dropped tables and their dependent 
objects are placed in the recycle bin. When the recycle bin is disabled, dropped tables 
and their dependent objects are no! placed in the recycle bin; thev are just dropped, 
and you must use other m.eans to recoyer them (such as recoyering from backup). 

The recycle bin is enabled by default. 

To disable the recycle bin: 

■ Issue one of the following statements: 

ALTER SES3I0H SET recyclebin = OFF; 
ALTER SYSTEM SET recyclebin = OFF; 

To enable the recycle bin: 

■ Issue one of the following statements: 

ALTER SESSIDM SET recyclebin = OH; 
ALTER SYSTEM SET recyclebin = OH; 

Enabling and disabling the recycle bin with an ALTER SYSTEM or ALTER SESSION 
statement takes effect immediately. Disabling the recycle bin does not purge or 
otherwise affect objects already in the recycle bin. 

Like any other initialization parameter, you can set the initial yaliie of the 
recyclebin parameter in the text initialization file initSJD,ora: 

recyclebin=on 

See Also: "Understanding Initialization Parameters" on page 2-23 
for more information on initialization parameters. 

Viewing and Querying Objects in the Recycle Bin 

Oracle Database provides tivo views for obtaining information about objects in the 
recycle bin: 

View Description 



USEIR_RECYCLEIBIN This view can be used by users to see their own dropped objects 

in the recycle bin. It has a svnonvm KECYCLEBIH, for ease of 
use. 



DBA_RECYCLEBIN This view gives administrators visibihty to all dropped objects 

in the recycle bin 



One use for these views is to identify the name that the database has assigned to a 
dropped object, as shown in the following example: 

SELECT □bject_naine, original_name FROM dba_recyclebin 
WHERE owner = ' HR ' ; 

OBiIECT.NAME ORIGIHSL_HAME 

BIN$yrMKlZaIjMhfgNAgAfflenRA==30 EMPLOYEES 



18-46 Oracle Database Administrator's Guide 



Using Flashback Drop and Managing the Recycle Bin 



You can also view the contents of the recycle bin using the SQL'Plus command SHOW 

RECYCLEBIW. 

S2L> show recyclebin 

ORIGINAL MfiME RECYCLEBIN MME OBJECT TYPE DROP TIME 

EMPLOYEES BIHSyrMKlZaVHhf gNAgAIMenRA==$ TABLE 2 003-10-27:14:00:19 

You can querj' objects that iire in the recycle bin, just as you can query other objects. 
However, you must specify the name of the object as it is identified in the recycle bin. 
For example: 

SELECT • FROM "BIHSyrMKlZaVMhf gHAgAIMeiiRA==SO" ; 



Purging Objects in the Recycle Bin 



If vou decide that vou are never going to restore an item from the recvcle bin, vou can 
use the PURGE statement to remove the items and their associated objects from the 
recycle bin and release their storage space. You need the same privileges as if vou 
were dropping the item. 

When you use the PURGE statement to purge a table, you can use the name that the 
table is known bv in the recycle bin or the original name of the table. The recvcle bin 
name can be obtained from either the DBA_ or USER_RECYCLEBIN view as shown in 
"Viewing and Querving Objects in the Recycle Bin" on page 18-46. The following 
hypothetical example purges the table hr . int_adinin_emp, which was renamed to 
BIN$jsleilx392nik2 = 293S0 when it was placed in the reci'cle bin: 

PURGE TABLE BIH$]sleilx392mk2=293S0; 

You can achieve the same result with the following statement: 

PURGE TABLE int_ad!iiin_emp; 

You can use the PURGE statement to purge all the objects in the recvcle bin that are 
from a specified tablespace or only the tablespace objects belonging to a specified user, 
as showfn in the following examples: 

PURGE TABLESPACE example; 

PURGE TABLESPACE example USER oe; 

Users can purge the recycle bin of their own objects, and release space for objects, by 
using the following statement: 

PURGE RECYCLEBIN; 

If VOU have the SYSDBA privilege, then you can purge the entire recvcle bin bv 
specifying DBA_RECYCLEBIN, instead of RECYCLEBIN in the previous statement. 

You can also use the PURGE statement to purge an index from the recycle bin or to 
purge from the recycle bin all objects in a specified tablespace. 

See Also: Oracle Database SQL Language Reference for more 
information on the PURGE statement 



Restoring Tables from tlie Recycle Bin 



Use the FLASHBACK TABLE ... TO BEFORE DROP statement to recover objects from the 
recycle bin. You can specifv either the name of the table in the recvcle bin or the 
original table name. An optional RENAME TO clause lets you rename the table as you 
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recover it. The recycle bin name can be obtained from either tlie DBA_ or 
USEE_RECYCLEBIW view as shown in "Viewing and Querying Objects in the Recycle 
Bin" on page 18-46. To use the FLASHBACK TABLE ... TO BEFORE DROP statement, you 
need the same privileges von need to drop the table. 

The following example restores int_admin_einp table and assigns to it a new name; 

FLASHBACK TABLE int_admin_eir[p TO BEFORE DROP 
RENAME TO irit2_admin_erap; 

The s\' stem- genera ted recj'cle bin name is very useful if \'ou have dropped a table 
multiple times. For example, suppose you have three versions of tlie 
int2_adinin_emp table in the recycle bin and you want to recover the second version. 
You can do this by issuing two FLASHBACK TABLE statements, or you can query the 
recycle bin and then flashback to the appropriate system- genera ted name, as shown in 
the following example. Including the create time in the query can help you verify that 
vou are restoring the correct table, 

SELECT object_riame, original_name, createtime FROM recyclebin; 

OBiIECT_NfflE ORIGIHAL_MfiME CREATETIME 

BIHSyrHKlZaLMhfgHAgAmenRA==30 IHT2_AnMIN_EMP 2006-02-05:21:05:52 
BINSyrMKlZaVMhfgHAgAIMenRA==SO INT2_ADMIH_EMP 2006-02-05:21:25:13 
BINSyrMKlZaQMhfgHAgAIMeiLRA==SO INT2_ADMIK_E1P 2006-02-05:22:05:53 

FLASHBACK TABLE BIH$yrHKlZaVMhfgMgAIHeiiRA==SO TO BEFORE DROP; 

Restoring Dependent Objects 

When vou restore a table from the recycle bin, dependent objects such as indexes do 
not get their original names back; they retain their system- genera ted recycle bin 
names. You must manually rename dependent objects if you want to restore their 
original names. If vou plan to manually restore original names for dependent objects, 
ensure that you make note of each dependent object's s\' stem- genera ted recycle bin 
name bcjbre you restore the table. 

The following is an example of restoring the original names of some of the indexes of 
the dropped table JOB_HISTORY, from the HR sample schema. The example assumes 
that you are logged in as the HR user. 

1. After dropping JOB_HLSTORY and before restoring it from the recycle bin, run the 
following query: 

SELECT OBJECT_NflME, ORIGIHAL_NAME, TYPE FROM RECYCLEBIEI; 

OBJECT_NAME ORIGIHAL_[JAME TYPE 

BIHSDBo9UChtZSbgQFeMiAdCcQ==S0 JHIST_JOB_IX IHDEX 

BINSDBo9UChuZSbgQFeMiAdCcQ==gO JHIST_EMPLOYEE_IX IMDEK 

BIHSDBo9UChvZSbgQFeMiAdCcQ==S0 JHIST_DEPARTMENT_IX IHDEX 

BIHSDBo9TJChwZSbgQFeMiAdCcQ==S0 JHIST_EMP_ID_ST_DATE_PK IHDEX 

BINSDBo9UChxZSbgQFeMiAdCcQ==30 JOB_HISTORY TABLE 

2. Restore the table with the following command: 

FLASHBACJ? TABLE JOB_HISTORY TO BEFORE DROP; 

3. Run the following query to verity that all JOB_HISTORY indexes retained their 
system -genera ted recycle bin names: 

SELECT IHDEX_HflHE FROM USERJNDEXES WHERE TABLE_NAME = ' J0B_HISTORY' ; 
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IMDEK HAME 



BI¥SDBo9UChijfiSbgQFeMiAdCcQ==S0 
BINSDBo9DQitZ3bgQFeMiAdCcQ==go 
BIHSDBo9UChuZ3bgQFeMiAdCcQ==30 
BIHSDBo9UQivZSbgQFeMiAdCcQ==S0 



4. Restore the original names of the first two indexes as follows: 

ALTER INDEX " BINSDBo9UChtZSbg(^FeMiAdCcQ==S " RENAME TO JHIST_JOB_IX ; 
ALTER INDEX " BINSDBo9UChuZSbgQFeMiAdCcQ==S " RENAME TO JHI3T_EMPL0YEE_IX; 

Note that double quotes are required around the system- generated names. 



Managing Index-Organized Tables 



This section describes aspects of managing index-organized tables, and contains the 
following topics: 

What Are Index-Organized Tables? 

Creating Index -Organized Tables 

Maintaining Index-Organized Tables 

Creating Secondary Indexes on Index -Organized Tables 

Analyzing Index-Organized Tables 

Using the ORDER BY Clause with Index-Organized Tables 

Conyerting Index-Organized Tables to Regular Tables 



What Are Index-Organized Tables? 



An index-organized table has a storage organization that is a yariant of a primary 
B-tree. Unlike an ordinary (heap- organized) table whose data is stored as an 
unordered collection (heap), data for an index -organized table is stored in a B-tree 
index structure in a primar;' key sorted manner. Each leaf block in the index structure 
stores both the key and nonlcey columns. 

The structure of an index -organized table provides the following benefits: 

■ Fast random access on the primary key because an index -only scan is sufficient. 
And, because there is no separate table storage area, changes to the table data 
(such as adding new rows, updating rows, or deleting rows) result only in 
updating the index structure. 

■ Fast range access on the primary key because the rows are clustered in primar}' 
key order. 

■ Lower storage requirements because duplication of priman' keys is avoided. Thev 
are not stored both in the index and underlying table, as is true with 

heap- organized tables. 

Index-organized tables have full table functionality. They support features such as 
constraints, triggers, LOB and object columns, partitioning, parallel operations, online 
reorganization, and replication. And, thev offer these additional features: 

■ Key compression 

■ Overflow storage area and specific column placement 
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■ Secondarv indexes, including bitmap indexes. 

Index- organized tables are ideal for OLTP applications, which require fast primary 
key access and high availability. Queries and DML on an orders table used in 
electronic order processing are predominantly primarv-key based and heavy volume 
causes fragmentation resulting in a frequent need to reorganize. Because an 
index -organized table can be reorganized online and without invalidating its 
secondarv indexes, the window of unavailability is greatly reduced or eliminated. 

Index- organized tables are suitable for modeling application- specific index structures. 
For example, content-based information retrieval applications containing text, image 
and audio data require inverted indexes that can be effectively modeled using 
index -organized tables, A fundamental component of an internet search engine is an 
inverted index that can be modeled using index- organized tables. 

These are but a few of the applications for index- organized tables. 

See Also: 

■ Oracle Database Concepts for a more thorough description of 
index -organized tables 

■ Oracle Database VLDB and Partitioning Guide for information 
about partitioning index -organized tables 



Creating Index-Organized Tables 



You use the CREATE TABLE statement to create index -organized tables, but you must 
provide additional information: 

■ An ORGANIZATION INDEX qualifier, which indicates that this is an 
index -organized table 

■ A primary key, specified through a column constraint clause (for a single column 
primary key) or a table constraint clause {for a multiple-column primary key). 

Optionally, you can specify the following: 

■ An OVERFLOW clause, which preserves dense clustering of the B-tree index bv 
enabling the storage of some of the nonkey columns in a separate overflow data 
segment, 

■ A PCTTHRESHOLD value, which, when an overflow segment is being used, defines 
the maximum size of the portion of the row that is stored in the index block, as a 
percentage of block size. Rows columns that would cause the row size to exceed 
this maximum are stored in the o\'erflow segment. The row is broken at a column 
boundary into two pieces, a head piece and tail piece. The head piece fits in the 
specified threshold and is stored along with the kev in the index leaf block. The 
tail piece is stored in the overflow area as one or more row pieces. Thus, the index 
entry contains the ke}' value, the nonkey column values that fit the specified 
threshold, and a pointer to the rest of the row, 

■ An INCLUDING clause, which can be used to specify the nonkey columns that are 
to be stored in the index block with the primary key. 

Example: Creating an Index-Organized Table 

The following statement creates an index-organized table: 

CREATE TABLE admin_doc index { 
token char (20), 
doc_id HUMBER, 
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token_frequency NUMBER, 

token_offset3 VARCHAR2 (2000) , 

COHSTRAIHT pk_adiiLin_doc index PEIMSEY KEY (token, doc_id) ) 
ORGMIZATION INDEX 
TABI£3PACE admin.tbs 
PCTTHHESHOLD 2 
OVERFLOW TflBLESPACE admin_tbE2 ; 

This example creates an index -organized table named admin_doc index, with a 
primary key composed of the columns token and doc_id. The OVERFLOW and 
PCTTHRESHOLD clauses specify that if the length of a row exceeds 20% of the index 
block size, then the column that exceeded that threshold and all columns after it are 
moved to the overflow segment. The overflow segment is stored in the adm.in_tbs 2 
table space. 

See Also: Oracle Database SQL Language Reference for more 
information about the syntax to create an index- organized table 

Restrictions for index-Organized Tables 

The following are restrictions on creating index -organized tables. 

■ The maximum number of columns is 1000, 

■ The maximum number of columns in the index portion of a row is 255, including 
both key and nonkev columns. If more than 255 columns are required, you must 
use an overflow segment. 

■ The maximum number of columns that you can include in the primary key is 32. 

■ PCTTHRESHOLD must be in the range of 1-50. The default is 50, 

■ All key columns must fit within the specified threshold, 

■ If the maximum size of a row exceeds 50% of the index block size and you do not 
specify an overflow segment, the CREATE TABLE statement fails, 

■ Index- organized tables cannot have virtual columns. 

Creating Index-Organized Tables that Contain Object Types 

Index- organized tables can store object t\'pes. The following example creates object 
t}'pe admin_tYp, then creates an index -organized table containing a column of object 
type admin_tYp: 

CREATE OR REPLACE TYPE adniin_typ AS OBJECT 

(coll HUMBER, col2 VARCHAR2 ( 6 ) ) ; 
CREATE TABLE admin_iot (cl MUMBER primary key, c2 admin_typ) 
ORGANIZATION INDEX; 

You can also create an index- organized table of object types. For example: 

CREATE TABLE adinin_iot2 OF adniin_typ (coll PRIMARY KEY) 
ORGANIZATION INDEX; 

Another example, that follows, shows that index -organized tables store nested tables 
efficiently. For a nested table column, the database internally creates a storage table to 
hold all the nested table rows. 

CREATE TYPE project_t AS OBJECT(pno NUMBER, pname VARCHAR2 ( 8 ) ) ; 

/ 

CREATE TYPE project_set AS TABLE OF project_t; 

/ 
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CREATE TftBLE pro]_tab (eno HDMBER, projects PROJECT_SET) 
MESTED TABLE projects STORE AS emp_pro j ect_tab 

{(PRIMAEY KEY[nested_table_id, prio) ) 
ORGABIZATIOH INDEX) 
RETDEM AS LOCATOR; 

The rows belonging to a single nested table instance are identified by a 
nested_table_id column. If an ordinary table is used to store nested table colun\ns, 
the nested table rows typicallv get de-clustered. But when vou use an index- organized 
table, the nested table rows can be clustered based on the nested_table_id column. 

See Also: 

■ Orach Database SQL Language Reference for details of the svntax 
used for creating index- organized tables 

■ Oracle Database VLDB and Partitioning Guide for inform.ation 
about creating partitioned index-organized tables 

■ Oracle Database Object-Relational Developer's Guide for 
information about object types 

Choosing and Monitoring aThresliold Value 

Choose a threshold value that can accommodate your key columns, as well as the first 
few nonkey columns (if they are frequently accessed). 

After choosing a threshold value, you can monitor tables to verifv that the value you 
specified is appropriate. You can use the ANALYZE TABLE ... LLST CHALWEDROWS 
statement to determine the number and identity of rows exceeding the threshold 
value. 

See Also: 

■ "Listing Chained Rows of Tables and Clusters" on page 16^ for 
more information about chained rows 

■ Oracle Database SQL Language Reference for svntax of the 
ANALYZE statement 

Using tiie INCLUDING Clause 

In addition to specifying PCTTHRESHOLD, you can use the INCLUDING clause to 
control which nonkey columns are stored with the key columns. The database 
accommodates all nonkev columns up to and including the column specified in the 
INCLUDING clause in the index leaf block, provided it does not exceed the specified 
threshold. All nonkey columns beyond the column specified in the INCLUDING clause 
are stored in the overflow segment. If the INCLUDING and PCTTHRESHOLD clauses 
confhct, PCTTHRESHOLD takes precedence. 
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Note: Oracle Database moves aU primarv key columns of an 
indexed- organized table to the beginning of the table {in their key 
order) to provide efficient primary key-based access. As an 
example: 

CREATE TABLE admiii_iot4 (a IHT, b INT, c INT, d IHT, 
primary key{c,b) ) 
ORGAMIZATION INDEX; 

The stored cokimn order is: c b a d (instead of: a. b c d). The 
last primarv key column is b, based on the stored column order 
The INCLUDING column can be the last primarv kev column (b in 
this example), or any nonkey column (that is, any column after b in 
the stored column order). 



The following CREATE TABLE statement is similar to the one shown earlier in 
"Example: Creating an Index-Organized Table" on page 18-50 but is modified to create 
an index- organized table where the token_of f sets column value is always stored 
in the overflow area: 

CEEATE TABLE admiii_docindex2 ( 

taken CHAR (20), 

doc_id NUMBER, 

token_frequency NUMBER, 

token_offsets VARCHAR2 (2000) , 

COHSTRAIHT pk_adinin_dociridex2 PRIMARY KEY (token, doc_id) } 
ORGANIZATION INDEX 
TABLESPACE admin_tbs 
PCTTHRESHOLD 2 
INCLUDING token_frequenc¥ 
OVERFLOW TABLESPACE admin_tbs2r 

Here, only nonkey columns prior to token_of f sets (in this case a single column 
only) are stored with the kev column values in the index leaf block. 

Parallelizing Index-Organized Table Creation 

The CREATE TABLE. ..AS SELECT statement enables you to create an 

index -organized table and load data from an existing table into it, Bv including the 

PARALLEL clause, the load can be done in parallel. 

The following statement creates an index-organized table in parallel bv selecting rows 
from the conventional table hr . jobs: 

CREATE TABLE admin_iot3 (i PRIMARY KEY, j, k, 1) 

ORGAHIZATIOH IHDEX 

PARALLEL 

AS SELECT ' FROM hr.jobs; 

This statement provides an alternative to parallel bulk-load using SQL*Loader. 

Using Key Compression 

Creating an index -organized table using key compression enables you to eliminate 
repeated occurrences of kev column prefix values. 

Key compression breaks an index key into a prefix and a suffix entrv. Compression is 
achieved by sharing the prefix entries among all the suffix entries in an index block. 
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This sharing can lead to huge savings in space, allowing you to store more keys in 
each index block while improving performance. 

You can enable kev compression using the COMPRESS clause while: 

■ Creating an index -organized table 

■ Moving an index -organized table 

You can also specify the prefix length (as the number of key columns), which identifies 
how the key columns are broken into a prefix and suffix entry. 

CliEATE TftBLE admin_iot5 (i IHT, j INT. k INT. 1 IHT, PRIMftRY KEY (i, j. k) ) 
ORGMIZ&TION INDEX COMPRESS; 

The preceding statement is equivalent to the following statement: 

CREATE TftBLE admin_iot6{i IHT. j INT, k INT, 1 INT, PRIMSRY KEY[i, j, k) ) 
ORGMIZATION INDEX COMPRESS l; 

For the list of values (1,2,3), (1,2,4), (1,2,7), (1,3,5), (1,3,4), (1,4,4) the repeated 
occurrences of (1,2), (1,3) are compressed away 

You can also override the default prefix length used for compression as follows: 

CREATE TftBLE admin_iot7(i INT, j INT, k INT, 1 INT, PRIMARY KEY (i, j, k) ) 
ORGANIZATION INDEX COMPRESS 1; 

For the list of values (1,2,3), (1,2,4), (1,2,7), (1,3,5), (1,3,4), (1,4,4), the repeated 
occurrences of 1 are compressed away. 

You can disable compression as follows: 

ALTER TABLE adniin_iot5 MOVE NOCOMPRESS; 

One application of key compression is in a time-series application that uses a set of 
time-stamped rows belonging to a single item, such as a stock price. Index- organized 
tables are attractive for such applications because of the ability to cluster rows based 
on the primary kev. By defining an index -organized table with primary key (stock 
symbol, time stamp), you can store and manipulate time-series data efficiently. You 
can achieve more storage savings by compressing repeated occurrences of the item 
identifier (for example, the stock symbol) in a time series by using an index-organized 
table with key compression. 

See Also: Oracle Database Concepts for more information about 
key compression 



Maintaining Index-Organized Tables 



Index- organized tables differ from ordinary tables only in physical organization. 
Logically, they are manipulated in the same manner as ordinary tables. You can 
specify an index -organized table just as you would specify a regular table in INSERT, 

SELECT, DELETE, and UPDATE statements. 

Altering Index-Organized Tabies 

All of the alter options available for ordinary tables are available for index- organized 
tables. This includes ADD, MODIFY, and DROP COLUMNS and CONSTRAINTS, However, 
the primary key constraint for an index -organized table cannot be dropped, deferred, 
or disabled 
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You can use the ALTER TABLE statement to modify physical and storage attributes 
for both primary key index and overflow data segments. All the attributes specified 
prior to the OVERFLOW keyword are applicable to the primary key index segment. All 
attributes specified after the OVERFLOW kev word are applicable to the overflow data 
segment. For example, vou can set the INI TRANS of the primary key index segment to 
4 and the overflow of the data segment INI TRANS to 6 as follows: 

ALTER TABLE adniin_docindex INITRANS 4 OVERFLOW IHITRMS 6; 

You can also alter PCTTHRESHOLD and INCLUDING column values. A new setting is 
used to break the row into head and overflow tail pieces during subsequent 
operations. For example, the PCTHRESHOLD and INCLUDING column values can be 
altered for the ad.min_d.ocind.ex table as follows: 

ALTER TABLE adniin_docindex PCTTHRESHOLD 15 IHCLUDIHG doc_id; 

By setting the INCLUDING column to doc_id, all the columns that follow 
token_f requency and token_of f sets, are stored in the overflow data segment. 

For index- organized tables created without an overflow data segment, vou can add an 
overflow data segment by using the ADD OVERFLOW clause. For example, you can add 
an overflow segment to table admin_iot3 as follows: 

ALTER TABLE adniin_iot3 ADD OVERFLOW TABLESPACE adinin_t±E2 ; 

Moving (Rebuilding) Index-Organized Tabies 

Because index- organized tables are primarih' stored in a B-tree index, you can 
encounter fragmentation as a consequence of incremental updates. However, vou can 
use the ALTER TABLE . . .MOVE statement to rebuild the index and reduce this 
fragmentation. 

The following statement rebuilds the index- organized table adniin_doc index: 

ALTER TABLE adniin_docindex MOVE; 

You can rebuild index -organized tables online using the ONLINE kevword. The 
overflow data segment, if present, is rebuilt when the OVERFLOW keyword is specified. 
For example, to rebuild the admin_docindex table but not the overflow data 
segment, perform a move online as follows: 

ALTER TABLE adniin_docindex MOVE OHLINE; 

To rebuild the admin_docindex table alongwith its overflow data segment perform 
the move operation as shown in the following statement. This statement also 
illustrates moving both the table and overflow data segment to new tablespaces. 

ALTER TABLE adniin_docindex MOVE TABLESPACE admin._tbE2 
OVERFLOW TABLESPACE admin_tbE3r 

In this last statement, an index -organized table with a LOB column (CLOB) is created. 
Later, the table is moved with the LOB index and data segment being rebuilt and 
moved to a new tablespace. 

CREATE TABLE admin_iot_lob 

(cl number (6) primary key, 
admin_lob CLOB) 
ORGAMIZATIOH INDEX 
LOB (admin_lob) STORE AS (TABLESPACE admin_t±s2 ) ; 
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ALTER TABLE adniin_iot_lob MOVE LOB {adminjob) STORE A3 (TABI£3PACE adniin_tbs3) ; 

See Also: Oracle Daiabase SeciircF ilcs and Large Objects Developer's 
Guide contains information about LOBs in index- organized tables 

Creating Secondary Indexes on Index-Organized Tables 

You can create secondary indexes on an index -organized tables to provide multiple 
access paths. Secondary indexes on index- organized tables differ from indexes on 
ordinary tables in two ways; 

■ They store logical rowids instead of physical rowids. This is necessary because the 
inherent movabilit}' of rows in a B-tree index results in the rows having no 
permanent physical addresses. If the physical location of a row changes, its logical 
rowid remains valid. One effect of this is that a table maintenance operation, such 
as ALTER TABLE ,,, MOVE, does not make the secondary index unusable. 

■ The logical rowid also includes a physical guess which identifies the database 
block address at which the row is likely to be found. If the physical guess is 
correct, a secondary index scan would incur a single additional I/O once the 
secondary key is found. The performance would be similar to that of a secondary 
index-scan on an ordinary table. 

Unique and non-unique secondary indexes, function-based secondary indexes, and 
bitmap indexes are supported as secondary indexes on index- organized tables. 

Creating a Secondary Index on an Index-Organized Table 

The following statement shows the creation of a secondary index on the docindex 
index-organized table where doc_id and token are the key columns: 

CliEATE JUDEX Doc_id_iridex on DocindeK(Doc_id, Token); 

This secondary index allows the database to efficiently process a query, such as the 
following, the involves a predicate on doc_id; 

SELECT Token FROM Docindex WHERE Doc_id = 1; 

Maintaining Physical Guesses in Logical Rowids 

A logical rowid can include a guess, which identifies the block location of a row at the 
time the guess is made. Instead of doing a full key search, the database uses the guess 
to search the block directly. However, as new rows are inserted, guesses can become 
stale. The indexes are still usable through the primary key-component of the logical 
rowid, but access to rows is slower. 

Collect index statistics with the DBMS_STATS package to monitor the staleness of 
guesses. The database checks whether the existing guesses are still valid and records 
the percentage of rows with valid guesses in the data dictionary. This statistic is stored 
in the PCT_DIRECT_ACCESS column of the DBA_INDEXES view (and related views). 

To obtain fresh guesses, you can rebuild the secondary index. Note that rebuilding a 
secondary index on an index-organized table involves reading the base table, unlike 
rebuilding an index on an ordinary table, A quicker, more light weight means of fixing 
the guesses is to use the ALTER IHDEX ,,, UPDATE BLOCK REFERENCES statement This 
statement is performed online, while DML is still allowed on the underlying 
index -organized table. 

After you rebuild a secondar}' index, or otherwise update the block references in the 
guesses, collect index statistics again. 
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Bitmap Indexes 

Bitmap indexes on index -organized tables are supported, provided the 

index -organized table is created with a mapping table. This is done bv specifying the 

MAPPING TABLE clause in the CREATE TABLE statement that you use to create the 

index -organized table, or in an ALTER TABLE statement to add the mapping table 

later. 

See Also: Oracle Database Concepts for a description of mapping 
tables 



Analyzing Index-Organized Tables 



Just like ordinary tables, index- organized tables are analyzed using the DBMS_STATS 
package, or the ANALYZE statement. 

Collecting Optimizer Statistics for index-Organized Tables 

To collect optimizer statistics, use the DBMS_STATS package. 

For example, the following statement gathers statistics for the index -organized 
countries table in the hr schema: 

EXECUTE DBMS_3TAT3 . GATHER_TABLE_STATS { ' HR ' , ' COUNTRIES ' ) ; 

The DBMS_STATS package analyzes both the primary key index segment and the 
overflow data segment, and computes logical as well as physical statistics for the table. 

■ The logical statistics can be queried using USER_TABLES,ALL_TABLES or 

DBA_TABLES. 

■ You can query the physical statistics of the primary kev index segment using 
USER_INDEXES, ALL_INDEXES or DBA_INDEXES (and using the primar}' key 
index name). For example, you can obtain the primary key index segment physical 
statistics for the table admin_docindex as follows: 

SELECT LA3T_ANALYZED, BLEVEL , LEAF_BL0CK3 , DISTINCT_KEY3 
FROM DBA_INDEXES WHERE IHDEX_HME= ' PK_ADMIH_DOC INDEX ' ; 

■ You can query the phvsical statistics for the overflow data segment using the 
USER_TABLES, ALL_TABLES or DBA_TABLES, You can identify the overflow 
entry by searching for IOT_TYPE = ' IOT_OVERFLOW ' , For example, you can 
obtain overflow data segment physical attributes associated with the 
admin_docindex table as follows: 

SELECT LA3T_ANALYZED, HUM_R01S, BLOCKS, EHPTY_BLOCKS 
FROM DBA_TABLE3 WHERE I0T_TYPE= ' I0T_0VERFLOW 
and I0T_NME= 'ADMIH.DOCIHDEX' ; 

See Also: 

■ Oracle Database Performance Tuning Guide for more information 
about collecting optimizer statistics 

■ Oracle Database PL/SQL Packages and Types Rejerence for more 
inform.ation about of the DBMS_STATS package 

Validating the Structure of index-Organized Tables 

Use the ANALYZE statement if vou want to validate the structure of your 

index -organized table or to list any chained rows. These operations are discussed in 

the following sections located elsewhere in this book: 
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"Validating Tables, Indexes, Clusters, and Materialized Views" on piige 16-3 
"Listing Chained Rows of Tables and Clusters" on page 16^ 



Note: There are special considerations when listing chained rows 
for index -organized tables. These are discussed in the Oracle 
Database SQL Language Reference. 

Using the ORDER BY Clause with Index-Organized Tables 

If an ORDER BY clause onlv references the primarv key column or a prefix of it, then 
the optimizer avoids the sorting overhead, as the rows are returned sorted on the 
primary key columns. 

The following queries avoid sorting overhead because the data is already sorted on the 
primar}' key: 

SELECT ' FROM admin_docindex2 ORDER BY token, doc_id; 
SELECT ' FROM admin_docindex2 ORDER BY token; 

If, however, vou have an ORDER BY clause on a suffix of the primar}' kev column or 
non-primary-kev columns, additional sorting is required (assuming no other 
secondary indexes are defined). 

SELECT ' FROM admin_docindex2 ORDER BY doc_id; 

SELECT ' FROM admin_docindex2 ORDER BY token_frequency; 

Converting index-Organized Tabies to Reguiar Tables 

You can convert index -organized tables to regular tables using the Oracle import or 
export utilities, or the CREATE TABLE ... AS SELECT statement. 

To convert an index -organized table to a regular table: 

■ Export the index- organized table data using conventional path. 

■ Create a regular table definition with the same definition, 

■ Import the index-organized table data, making sure IGNORE=y (ensures that 
object exists error is ignored). 



Note: Before converting an index-organized table to a regular 
table, be aware that index -organized tables cannot be exported 
using pre-Oracle8 versions of the Export utility. 



See Also: Oracle Database Utilities for more details about using the 

IMPORT and EXPORT utilities 



Managing External Tables 



Oracle Database allows you read-only access to data in external tables. External tables 
are defined as tables that do not reside in the database, and can be in any format for 
which an access driver is provided. Bv providing the database with metadata 
describing an external table, the database is able to expose the data in the external 
table as if it were data residing in a regular database table. The external data can be 
queried directly and in parallel using SQL, 
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YoLL can, for example, select, join, or sort external table data. You can also create views 
and svnonvms for external tables. However, no DML operations (UPDATE, INSERT, or 
delete) are possible, and no indexes can be created, on external tables. 

External tables also provide a framework to unload the result of an arbitrary SELECT 
statement into a platform-independent Oracle- proprietary format that can be used by 
Oracle Data Pump. 



Note: The DBMS_STATS package can be used for gathering 
statistics for external tables. The ANALYZE statement is not 
supported for gathering statistics for external tables. 

For information about using the DBMS_STATS package, see Oracle 
Database Performance Tuning Guide 

The means of defining the ntetadata for external tables is through the CREATE 
TABLE. . .ORGANIZATION EXTERNAL statement. This external table definition can be 
thought of as a view that allows running anv SQL quer;' against external data without 
requiring that the external data first be loaded into the database. An access driver is 
the actual mechanism used to read the external data in the table. When you use 
external tables to unload data, the metadata is automaticallv created based on the 
datatypes in the SELECT statement (sometimes referred to as the shape of the query), 

Oracle Database provides two access drivers for external tables. The default access 
driver is ORACLE_LOADER, which allows the reading of data from external files using 
the Oracle loader technology. The ORACLE_LOADER access driver provides data 
mapping capabilities which are a subset of the control file syntax of SQL'Loader 
utilit\'. The second access driver, ORACLE_DATAPUMP, lets you unload data— that is, 
read data from the database and insert it into an external table, represented bv one or 
more external files—and then reload it into an Oracle Database. 

The Oracle Database external tables feature provides a valuable means for performing 
basic extraction, transformation, and loading (ETL) tasks that are common for data 
warehousing. 

These following sections discuss the DDL statements that are supported for external 
tables. Only DDL statements discussed are supported, and not all clauses of these 
statements are supported, 

■ Creating External Tables 

■ Altering External Tables 

■ Dropping External Tables 

■ System and Object Privileges for External Tables 

See Also: 

■ Oracle Database Utilities contains more information about 
external tables and describes the access drivers and their access 
parameters 

■ Oracle Database Data Warehousing Guide for information about 
using external tables in a data warehousing environment 



Creating External Tables 



You create external tables using the ORGANIZATION EXTERNAL clause of the CREATE 
TABLE statement You are not in fact creating a table; that is, an external table does not 
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have any extents associated with it. Rather, \'oii are creating metadata in the data 
dictionary that enables you to access external data. 



Note: External tables cannot have virtual columns. 



The following example creates an external table and then uploads the data to a 
database table. Alternatively, you can unload data through the external table 
framework bv specifying the AS suiiguer^' clause of the CREATE TABLE statement. 
External table data pump unload can use only the ORACLE_DATAPUMP access driver. 

EXAMPLE: Creating an External Table and Loading Data 

The file empxtl . dat contains the following sample data: 

360, Jane, Janus, ST_CLERK, 121, n-MAY-2 001, 3000,0, 50, jjanus 
361,Mark, Jasper, SA_REP, 145, n-MAY-2 001, 8000, .1, 80,mjasper 
362, Erenda, Starr, AD_ASST. 200. 17 -MAY-2 001, 5500,0. 10, bstarr 

363,Alex,Alda,AC_MGR,145,17-MAY-2001,9000, .15,80,aalda 

The file enipxt2 . dat contains the following sample data: 

401, Jesse. Cromwell,HR_REP, 203, 17-MftY-2 001, 7000,0, 4 O,jcromwel 
402, Abby,Applegate,IT_PROG, 103, 17-MAY-2 001, 9000. .2 , 60, aapplega 
403, Carol, Cousins, AD_VP, 100, 17-MAY-2 001. 27000, .3, 90,ccousinE 
404, John, Richardson, AC_ACCOUNT, 2 05, 17-MAY-2 001, 5000,0, 110, jrichard 

The following hypothetical SQL statements create an external table in the hr schema 
named admin_ext_einploYees and load its data into the hr . employees table, 

COMNECT / A3 SYSDBA; 

— Set up directories and grant access to hr 
CREATE OR REPLACE DIRECTORY admin_dat_dir 

AS 7flatfiles/data' ; 
CREATE OR REPLACE DIRECTORY adinin_log_dir 

AS 7flatfiles/log' ; 
CREATE OR REPLACE DIRECTORY adinin_bad_dir 

AS 7flatfiles/bad' ; 
GRAHT READ OH DIRECTORY adinin_dat_dir TO hr; 
GRAFT WRITE ON DIRECTORY adinin_log_dir TO hr; 
GRANT WRITE OM DIRECTORY adinin_bad_dir TO hr; 

— hr connects. Provide the user password (hr) when prompted. 
COMNECT hr 

-- create the external table 
CREATE TABLE admin_ext_employees 

{employee_id NUMBER(4) . 

first_name VARCHAR2 (20) , 

laEt_name VARCHAR2 (25), 

job_id VARCHAR2{10) , 

manager_id NUMBER (4 ) , 

hire_date DATE, 

salary HUMBER(8,2), 

commiEsion_pct HUMBER(2,2), 

departinent_id HUMBER(4) . 

email VARCHAR2{25) 

) 
ORGAHIZATION EXTERNAL 

( 

TYPE ORACLE_LOADER 

DEFAULT DIRECTORY admin dat dir 
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ACCESS PAEftMETERS 
( 

records delimited by newline 

badfile adiniri_bad_dir : ' empxt^a^P -bad' 

logfile adiniri_log_dir : ' einpxt^a^P ■ log' 

fields terminated by ' , ' 

missing field values are null 

( employee_id, first_nanie, last_name, job_id, manager_id, 
hire_date char date_foniiat date mask "dd-mon-yyyy" , 
salary, coramission_pct, departinent_id, email 



LOCATION {'empxtl.daf, 'empxt2.dat'} 
) 

PARALLEL 

REJECT LIMIT UMLIMITED; 
-- enable parallel for loading {good if lots of data to load) 
ALTER SES3I0H ENABLE PARALLEL DML; 
-- load the data in hr employees table 

INSERT INTO employees (employee_id, f irs t_naiiie , last_naiiie, job_id, manager_id, 
hire_date, salary, coramisEion_pct, department_id, email) 
SELECT ' FROM admin_ext_employeeE ; 

The following paragraphs contain descriptive information about this example. 

The first few statements in this example create the directory objects for the operating 
system directories that contain the data sources, and for the bad record and log files 
specified in the access parameters. You must also grant READ or WRITE directory 
object privileges, as appropriate. 

Note: When creating a directory object or BFILEs, ensure that the 
following conditions are met: 

■ The operating system file must not be a symbolic or hard link. 

■ The operating system directory path named in the Oracle 
Database directory object must be an existing OS directory 
path. 

■ The operating system directory path named in the directory 
object should not contain any symbolic hnks in its components. 



The TYPE specification indicates the access driver of the external table. The access 
driver is the API that interprets the external data for the database. Oracle Database 
provides two access drivers: ORACLE_LOADER and ORACLE_DATAPUMP. If you omit 
the TYPE specification, ORACLE_LOADER is the default access driver. You must specify 
the ORACLE_DATAPUMP access driver if you specify the AS suiig'uer^y clause to 
unload data from one Oracle Database and reload it into the same or a different Oracle 
Database. 

The access parameters, specified in the ACCESS PARAMETERS clause, are opaque to 
the database. These access parameters are defined by the access driver, and are 
provided to the access driver by the database when the external table is accessed. See 
Oracle Database Utilifks for a description of the ORACLE_LOADER access parameters. 

The PARALLEL clause enables paraUel query on the data sources. The granule of 
parallelism is by default a data source, but parallel access within a data source is 
implemented whenever possible. For example, if PARALLEL=3 were specified, then 
more than one parallel execution server could be working on a data source. But, 
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parallel access within a data source is provided bv the access driver only if all of the 
following conditions are met: 

■ The media allows random positioning within a data source 

■ It is possible to find a record boundary from a random position 

■ The data files are large enough to make it worthwhile to break up into multiple 
chunks 



Note: Specifying a PARALLEL clause is of value only when dealing 
with large amounts of data. Otherwise, it is not advisable to specify 
a PARALLEL clause, and doing so can be detrimental. 

The REJECT LIMIT clause specifies that there is no limit on the number of errors that 
can occur during a querv of the external data. For parallel access, this limit applies to 
each parallel execution sen'er independentlv. For example, if REJECT LIMIT is 
specified, each parallel querj' process is allowed 10 rejections. Hence, the only 
precisely enforced values for REJECT LIMIT on parallel query are and UNLIMITED. 

In this example, the INSERT INTO TABLE statement generates a dataflow from the 
external data source to the Oracle Database SQL engine where data is processed. As 
data is parsed bv the access driver from the external table sources and provided to the 
external table interface, the external data is converted from its external representation 
to its Oracle Database internal dataKpe. 

See Also: Oracle Database SQL Language Reference provides details 
of the syntax of the CREATE TABLE statement for creating external 
tables and specifies restrictions on the use of clauses 



Altering External Tables 

You can use any of the ALTER TABLE clauses shown in Table 18-3 to change the 
characteristics of an external table. No other clauses are permitted. 

Table 18-3 ALTER TABLE Clauses for External Tables 



ALTER TABLE 






Clause 


Description 


Example 


REJECT 


Changes the reject limit 


ALTER TABLE admin_ext_employees 


LIMIT 




REJECT TiTMTT 100; 


PROJECT 


DeterinineE how the access driver validates 


ALTER TABLE admin_ext_emploYees 


COLUMN 


rows in subsequent queries: 

■ PROJECT COLUMM REt'EREHCED: the 


PROJECT COLUMN REFERMCED; 




access driver processes onlv the columns 


ALTER TABLE adinin_ext_employees 




in the select list of the query, Tliis setting 


PROJECT COLUMN ALL; 




may not provide a consistent set of rows 






when quervmg a different column list 






from the same external table. This is the 






default. 






■ PROJECT COLUMN ALL: the access driver 






processes all of the columns defined on 






the external table. Tliis setting always 






provides a consistent set of rows when 






querying an external table. 




DEFAULT 


Changes the default directory specification 


ALTER TABLE adinin_ext_eiiiployees 


DIRECTORY 




DEFAULT DIRECTORY adinin_dat2_diir,- 
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Table 18-3 (Cont.) ALTER TABLE Clauses for External Tables 



ALTER TABLE 
Clause 


Description 


Example 


ACCESS 
PARAMETERS 


Allows access parameters to be changed 
without dropping and re-creating the external 
table metadata 


ALTER TABLE admin_ext_eir[ployees 
ACCESS PARftMETERS 

(FIELDS TERMINATED BY ' ; ' } ; 


LOCATION 


Allows data sources to be changed without 
dropping and re-creating the external table 
metadata 


ALTER TABLE adinin_ext_eanployees 
LOCATION CejipxtS.txf , 
1 ' eiiipxt4 . txt' ) ; 


PARALLEL 


No difference from regular tables. Allows 
degree of parallelism to be changed. 


No new syntax 


ADD COLUMH 


No difference from regular tables. Allows a 
column to be added to an external table. 
Virtual columns are not permitted. 


No new syntax 


MODIFY 
COLUMH 


No difference from regular tables. Allows an 
external table column to be modified. Virtual 
columns are not permitted. 


No new syntax 


SET UHUSED 


Transparently converted into an ALTER 
TABLE DROP COLUMH command. Because 
external tables consist of metadata only in the 
database, the DROP COLUMH command 
performs equivalently to the SET UHUSED 
command. 


No new syntax 


DROP COLUMH 


No difference from regular tables. Allows an 
external table column to be dropped. 


No new syntax 


RENAME TO 


No difference from, regular tables. Allows 
external table to be renamed. 


No new syntax 

1 



Dropping External Tables 

For an external table, the DROP TABLE statement removes onlv the table metadata in 
the database. It has no affect on the actual data, which resides outside of the database. 

System and Object Privileges for External Tables 

System and object privileges for external tables are a subset of those for regular table. 
Only the following system privileges are applicable to external tables: 

■ CREATE ANY TABLE 

■ ALTER ANY TABLE 

■ DROP ANY TABLE 

■ SELECT ANY TABLE 

Only the following object privileges are applicable to external tables: 

■ ALTER 

■ SELECT 

However, object privileges associated with a directory are: 

■ READ 

■ WRITE 
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For external tables, READ privileges are required on directory objects that contain data 
sources, while WRITE privileges are required for directory objects containing bad, log, 
or discard files. 



Tables Data Dictionary Views 



The following views allow you to access information about tables. 



1 View 


Description 


DBA_TABLES 
ALL_TABLE3 
USEE_TABLES 


DBA view describes all relational tables in the database. ALL view describes all 
tables accessible to the user, USER view is restricted to tables owned by the 
user. Some columns in these views contain statistics that are generated by the 
DBMS_STATS package or ANALYZE statement. 


DBA_TAB_COLUMHS 
ALL_TAB_COLUMHS 
DSER_TAB_COLUMHS 


These views describe the columns of tables, views, and clusters in the 
database. Some columns in these views contain statistics that are generated 

by the DBMS_STATS package or AHALYZE statement. 


DBA_ALL_TABLES 
ALL_ALL_TABLES 
USER_ALL_TABLES 


These views describe all relational and object tables in the database. Object 
tables are not specificallv discussed in this book. 


DBA_TAB_COMMEHTS 
ALL_TAB_COMMEHTS 
USER_TAB_COMMEHTS 


These views display comments tor tables and views. Com.ments are entered 
using the COMMEHT statement 


DBA_COL_COMHEHTS 
ALL_COL_COMMEHTS 
USER_COL_C0MMEHTS 


These views display comments for table and view columns. Comments are 
entered using the COMMEHT statement. 


DBA_EXTERHAL_TABLES 

ALL_EXTERHAL_TABLES 
DSER_EXTEEHAL_TABLES 


These views list the specific attributes ot external tables in the database. 


DBA_EXTERHAL_LOCAT I OHS 
ALL_EXTERHAL_LOCAT I OHS 
DSER_EXTERMAL_LOCATI ONS 


These views list the data sources tor external tables. 


DBA_TAB_HI STOGRAMS 
ALL_TAB_HI STOGRAMS 
DSER_TAB_HISTOGRAMS 


These views describe histograms on tables and views. 


DBA_TAB_S TATIS TICS 
ALL_TAB_S TATIS TICS 
DSER_TAB_S TATIS TICS 


These views contain optimizer statistics for tables. 


DBA_TAB_COL_STATIS TI CS 
ALL_TAB_COL_STATIS TI CS 
USER_TAB_COL_STATISTICS 


These views provide column statistics and histogram information extracted 
from the related TAB_COLUMHS views. 


DBA_TAB_MODIFICATIOUS 

ALL_TAB_MODIFICATIOHS 
DSER_TAB_MODIF I CAT I OHS 


These views describe tables that have been modified since the last time table 
statistics were gathered on them. They are not populated immediately, but 
after a time lapse (usually 3 hours). 
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View 


Description 


DBA_EHCRYPTED_COLUMNS 

USER_EHCRYPTED_COLUMUS 
ALL_EHCRYPTED_COLOMHS 


These views list tshle columns ti\st are encrypted, and for each column, lists 
the encryption algorithm in use. 


DBA_"DHUSED_COL_TftBS 
ALL_UmJSED_COL_TaBS 
USER_UMUSED_COL_TABS 


These views list tables with unused columns, as marked by the ALTER 

TABLE . . . SET DHUSED statement. 


DBA_PAETIAL_DROP_TABS 
ALL_PAETIAL_DROP_TABS 
USER_PART I AL_DROP_TABS 


These views list tables that have partially completed DROP COLUMH 
operations. These operations could be incomplete because the operation was 
interrupted by the user or a system failure. 



Example: Displaying Column Information 

Column mformation, such as name, datatype, length, precision, scale, and default data 
values can be listed using one of the views ending with the _COLUMNS suffix. For 
example, the following query lists all of the default column values for the emp and 
dept tables; 

SELECT TABLE_NAME, COLHMN_HME, DATA_T¥PE, DATA_LENGTH, LA3T_ANALYZED 
FROM DBA_TAB_COLUMNS 
WHERE OWMER = 'HR' 
ORDER BY TABLE_NftME: 

The following is the output from the query: 

TABLE NAME COLUMN MAME DATA TYPE DATA LENGTH LAST ANALYZED 



COUNTRIES 

COUNTRIES 

COUNTRIES 

DEPARTMENTS 

DEPARTMENTS 

DEPARTMENTS 

DEPARTMENTS 

EMPLOYEES 

EMPLOYEES 

EMPLOYEES 

EMPLOYEES 



COUMTRY.ID 

COUMTEYJAME 

REGION_ID 

DEPARTMENT_ID 

DEPARTMENT_HME 

MANAGER_ID 

LOCATI0M_ID 

EMPLOYEE_ID 

FIRST_HAME 

LAST_NAME 

EMAIL 



CHAR 

VARCHAR2 

NUMBER 

NUMBER 

VARCHAR2 

NUMBER 

NUMBER 

NUMBER 

VARCHAR2 

VARCHAR2 

VARCHAR2 



2 05-FEB-03 
40 05-FEB-03 
22 05-FEB-03 
22 05-FEB-03 
30 05-FEB-03 
22 05-FEB-03 
22 05-FEB-03 
22 05-FEB-03 
20 05-FEB-03 
25 05-FEB-03 
25 05-FEB-03 



LOCATIONS 


COUNTRY ID 


CHAR 


REGIONS 


REGION ID 


NUMBER 


REGIONS 


REGION NAME 


VARCHAR2 



2 05-FEB-03 
22 05-FEB-03 
25 05-FEB-03 



51 rows selected. 
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See Also: 



Oracle Database Reference for complete descriptions of these 
views 

Oracle Database Object-Relational Developer's Guide for 
information about object tables 

Oracle Database Performance Tuning Guide for information about 
iiistograms and generating statistics for tables 

"Analyzing Tables, Indexes, and Clusters" on page 16-2 
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Managing Indexes 



In this chapter; 
About Indexes 

Guidelines for Managing Indexes 
Creating Indexes 
Altering Indexes 
Monitoring Space Use of Indexes 
Dropping Indexes 
Indexes Dat.i Dictionar\' Views 



About Indexes 



Indexes are optional structures associated with tables and clusters that allow SQL 
statements to execute more quickly against a table. Just as the index in this manual 
helps vou locate information faster than if there were no index, an Oracle Database 
index provides a faster access path to table data. You can use indexes without 
rewriting anv queries. Your results are the same, but you see them more quickly. 

Oracle Database provides several indexing schemes that provide complementary 
performance functionality. These are: 

B-tree indexes: the default and the most common 

B-tree cluster indexes: defined specifically for cluster 

Hiish cluster indexes: defined specifically for a hash cluster 

Global and local indexes: relate to partitioned tables and indexes 

Reverse key indexes: most useful for Oracle Real Application Clusters applications 

Bitmap indexes: compact; work best for columns with a small set of values 

Function-based indexes: contain the precomputed value of a function /expression 

Domain indexes: specific to an application or cartridge. 

Indexes are logically and phvsicallv independent of the data in the associated table. 
Being independent structures, thev require storage space. You can create or drop an 
index without affecting the base tables, database applications, or other indexes. The 
database automatically maintains indexes when vou insert, update, and delete rows of 
the associated table. If vou drop an index, all applications continue to work. However, 
access to previously indexed data might be slower. 
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See Also: Chapter 17, "Managing Space for Schema Objects" is 
recommended reading before attempting tasks described in this 
chapter. 



Guidelines for l\/lanaging Indexes 



This section discusses giiidehnes for managing indexes and contains the following 
topics: 

Create Indexes After Inserting Table Data 

Index the Correct Tables and Columns 

Order Index Columns for Performance 

Limit the Number of Indexes for Each Table 

Drop Indexes That Are No Longer Required 

EsHm.ate Index Size and Set Storage Parameters 

Specify the Tablespace for Each Index 

Consider Parallelizing Index Creation 

Consider Creating Indexes with NOLOGGING 

Consider Costs and Benefits of Coalescing or Rebuilding Indexes 

Consider Cost Before Disabling or Dropping Constraints 

See Also: 

■ Orack' Database ConaySs for conceptual information about 
indexes and indexing, including descriptions of the various 
indexing schemes offered bv Oracle 

■ Oracle Database Performance Timing Guide and Oracle Database 
Data Warehousing Guide for information about bitmap indexes 

■ Oracle Database Data Cartridge Developer's Guide for information 
about defining do main- specific operators and indexing 
schemes and integrating them into the Oracle Database server 



Create Indexes After Inserting Table Data 



Data is often inserted or loaded into a table using either the SQL'Loader or an import 
utility. It is more efficient to create an index for a table after inserting or loading the 
data. If you create one or more indexes before loading data, the database then must 
update every index as each row is inserted. 

Creating an index on a table that already has data requires sort space. Some sort space 
comes from memory allocated for the index creator. The amount for each user is 
determined by the initialization parameter SOET_AEEA_SIZE. The database also 
swaps sort information to and from temporary segments that are only allocated during 
the index creation in the users temporary tablespace. 

Under certain conditions, data can be loaded into a table with SQL'Loader direct-path 
load and an index can be created as data is loaded. 

See Also: Oracle Database Utilities for information about using 
SQL*Loader for direct-path load 
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Index the Correct Tables and Columns 

Use the following guidelines for determining when to create an index: 

■ Create an index if von frequently want to retrieve less than 15% of the rows in a 
large table. The percentage varies greatly according to the relative speed of a table 
scan and how the distribution of the row data in relation to the index kev. The 
faster the table scan, the lower the percentage; the more clustered the row data, the 
higher the percentage. 

■ To improve performance enjoins of multiple tables, index columns used for joins. 



Note: Primary and unique keys automatically have indexes, but 
you might want to create an index on a foreign key. 

■ Small tables do not require indexes. If a query is taking too long, then the table 
might have grown from small to large. 

Columns That Are Suitable lor Indexing 

Some columns are strong candidates for indexing. Columns with one or more of the 
ollowing characteristics are candidates for indexing: 

Values are relatively unique in the column. 

There is a wide range of values (good for regular indexes). 

There is a small range of values (good for bitmap indexes). 

The column contains many nulls, but queries often select all rows having a value. 
In this case, use the following phrase: 

MHERE COL_X > -9.99 * power (10, 125) 

Using the preceding phrase is preferable to: 

MHERE COL_X IS NOT HULL 

This is because the first uses an index on COL_X (assuming that COL_X is a 
numeric column). 

Columns That Are Not Suitable lor Indexing 

Columns with the following characteristics are less suitable for indexing: 

■ There are many nulls in the column and you do not search on the not null values, 
LONG and LONG RAW columns cannot be indexed. 

Virtual Columns 

You can create unique or non-unique indexes on virtual columns. 



Order Index Columns for Performance 



The order of columns in the CREATE INDEX statement can affect querv performance. 
In general, specifv the most frequently used columns first. 

If vou create a single index across columns to speed up queries that access, for 
example, coll, col 2, and col 3; then queries that access just coll, or that access just 
coll and col 2, are also speeded up. But a querv that accessed just col 2, just col 3, 
or just CO 12 and col 3 does not use the index. 
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Limit the Number of Indexes for Each Table 

A table c.in have nnv number of indexes. However, the more indexes there are, the 
more overhead is incurred as the table is modified. Specificnilv, when rows are 
inserted or deleted, all indexes on the table must be updated as well. Also, when a 
column is updated, all indexes that contain the column must be updated. 

Thus, there is a trade-off between the speed of retrieving data from a table and the 
speed of updating the table. For example, if a table is primarily read-onlv, having 
more indexes can be useful; but if a table is heavily updated, having fewer indexes 
could be preferable. 

Drop Indexes That Are No Longer Required 

Consider dropping an index if: 

■ It does not speed up queries. The table could be very small, or there could be 
many rows in the table but very few index entries. 

■ The queries in vour applications do not use the index. 

■ The index must be dropped before being rebuilt. 

See Also: "Monitoring Index Usage" on page 19-14 

Estimate Index Size and Set Storage Parameters 

Estimating the size of an index before creating one can facilitate better disk space 
planning and management. You can use the combined estimated size of indexes, along 
with estimates for tables, the undo tablespace, and redo log files, to determine the 
amount of disk space that is required to hold an intended database. From these 
estimates, vou can make correct hardware purchases and other decisions. 

Use the estimated size of an individual index to better manage the disk space that the 
index uses. When an index is created, vou can set appropriate storage parameters and 
improve I/O performance of applications that use the index. For example, assume that 
you estimate the maximum size of an index before creating it. If you then set the 
storage parameters when you create the index, fewer extents are aUocated for the table 
data segment, and all of the index data is stored in a relatively contiguous section of 
disk space. This decreases the time necessarv for disk I/O operations involving this 
index. 

The maximum size of a single index entry is approximatelv one-half the data block 
size. 

See Also: "Managing Storage Parameters" on page 17-5 for 
specific information about storage parameters 



Specify the Tablespace for Each Index 



Indexes can be created in any tablespace. An index can be created in the same or 
different tablespace as the table it indexes. If you use the same tablespace for a table 
and its index, it can be more convenient to perform database maintenance (such as 
tablespace or file backup) or to ensure application availability'. All the related data is 
alwavs online together 

Using different tablespaces (on different disks) for a table and its index produces 
better performance than storing the table and index in the same tablespace. Disk 
contention is reduced. But, if you use different tablespaces for a table and its index and 
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one tiiblespace is offline (containing either data or index), then the statements 
referencing that table are not guaranteed to work. 



Consider Parallelizing Index Creation 

YoLL can parallelize index creation, much the same as you can parallelize table 
creation. Because multiple processes work together to create the index, the database 
can create the index more quicklv than if a single server process created the index 
sequentially. 

When creating an index in parallel, storage parameters are used separately by each 
query ser\'er process. Therefore, an index created with an INITIAL value of 5M and a 
parallel degree of 12 consumes at least 60M of storage during index creation. 

See Also: 

■ Oracle Database Concepts for more information about parallel 
execution 

■ Onicic Database Data Warelwiisiug Guide for information about 
utilizing parallel execution in a data warehousing envirorunent 

Consider Creating Indexes with NOLOGGING 

You can create an index and generate minimal redo log records bv specifying 
HOLOGGING in the CREATE INDEX statement. 

Note: Because indexes created using NOLOGGING are not 
archived, perform a backup after vou create the index. 

Creating an index with NOLOGGING has the following benefits: 

■ Space is saved in the redo log files. 

■ The time it takes to create the index is decreased. 

■ Perform.ance improves for parallel creation of large indexes. 

In general, the relative performance improvement is greater for larger indexes created 
without LOGGING than for smaller ones. Creating small indexes without LOGGING has 
httle effect on the time it takes to create an index. However, for larger indexes the 
performance improvement can be significant, especially when you are also 
parallelizing the index creation. 

Consider Costs and Benefits of Coalescing or Rebuilding Indexes 

Improper sizing or increased growth can produce index fragmentation. To eliminate 
or reduce fragmentation, vou can rebuild or coalesce the index. But before vou 
perform either task weigh the costs and benefits of each option and choose the one that 
works best for your situation. Table 19—1 is a comparison of the costs and benefits 
associated with rebuilding and coalescing indexes. 

Table 19-1 To Rebuild or Coalesce ... That Is the Question 
Rebuild Index Coalesce Index i 

Quickly moves index to another tdblespace Cannot move mdex to another tablespace ' 

Higher costs: requires more disk space Lower costs: does not require more disk space 
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Table 19-1 (Cont.) To Rebuild or Coalesce ... That Is the Question 

Rebuild Index Coalesce Index 

Creiites new tree, shrinks height if Coalesces leaf blocks within same branch of 

applicable tree 

Enables you to quickly change storage and Quickly frees up index leaf blocks for use. 
tablespace parameters without having to 
drop the original index. 



In situations where you have B-tree index leaf blocks that c.in be freed up for reuse, 
you can merge those leaf blocks using the following statement: 

ALTER INDEX vinoore C0AI£3CE; 

Figure 19-1 illustrates the effect of an ALTER INDEX COALESCE on the index 
vmoore. Before performing the operation, the first two leaf blocks are 50% full. This 
means vou ha\'e an opportunitv to reduce fragmentation and compteteiv fill the first 
block, while freeing up the second. 

Figure 19-1 Coalescing Indexes 

B-tree Index B-tree Index 





Before ALTER INDEX vmoore COALESCE; After ALTER INDEX vmoore COALESCE; 

Consider Cost Before Disabling or Dropping Constraints 

Because unique and primary keys have associated indexes, vou should factor in the 
cost of dropping and creating indexes when considering whether to disable or drop a 
UNIQUE or PRIMARY KEY constraint. If the associated index for a UNIQUE key or 
PRIMARY KEY constraint is extremelv large, vou can save time by leaving the 
constraint enabled rather than dropping and re-creating the large index. You also have 
the option of exphcitiv specifying that vou want to keep or drop the index when 
dropping or disabling a UNIQUE or PRIMARY KEY constraint. 

See Also: "Managing Integrity' Constraints" on page 16-9 

Creating Indexes 

This section describes how to create indexes. To create an index in vour own schema, 
at leas! one of the following conditions must be true: 

■ The table or cluster to be indexed is in your own schema. 

■ You have INDEX privilege on the table to be indexed. 

■ You have CREATE ANY INDEX system privilege. 
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To create an index in another sctiema, (7^/ of the following conditions must be true: 

■ You have CREATE ANY INDEX system privilege. 

■ The owner of the other schema has a quota for the tablespaces to contain the index 
or index partitions, or UNLIMITED TABLESPACE system privilege. 

This section contains the following topics: 

Creating an Index Exphcitly 

Creating a Unique Index Explicitly 

Creating an Index Associated with a Constraint 

Collecting Incidental Statistics when Creating an Index 

Creating a Large Index 

Creating an Index Online 

Creating a Function-Based Index 

Creating a Key-Compressed Index 

Creating an Invisible Index 



Creating an Index Explicitly 



You can create indexes explicitly (outside of integrity constraints) using the SQL 
statement CREATE INDEX. The following statement creates an index named 
emp_enaine for the ename column of the emp table: 

□ffiATE IHDEX erap_ename OM emp (ename) 
TABLESPACE users 
STORAGE (INITIAL 2 OK 
NEXT 2 0k 
PCTINCREASE 75) ; 

Notice that several storage settings and a tablespace are explicitly specified for the 
index. If you do not specify storage options (such as INITIAL and NEXT) for an index, 
the default storage options of the default or specified tablespace are automatically 
used. 

See Also: Oracle Database SQL Ijiiiguage Kcfcrciia: for syntax and 
restrictions on the use of the CREATE INDEX statement 



Creating a Unique Index Explicitly 



Indexes can be unique or non-unique. Unique indexes guarantee that no two row^s of a 
table have duplicate values in the key column (or columns). Non-unique indexes do 
not impose this restriction on the column values. 

Use the CREATE UNIQUE INDEX statement to create a unique index. The following 
example creates a unique index: 

CREAIE UMIQHE INDEX dept_unique_index OM dept (dname) 
TABLESPACE indx; 

Alternatively, you can define UNIQUE integrity constraints on the desired columns. 
The database enforces UNIQUE integrity constraints bv automatically defining a 
unique index on the unique key. This is discussed in the following section. However, it 
is advisable that any index that exists for quer\' performance, including unique 
indexes, be created explicitly. 
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See Also: Oracle Database Performanee Tuning Guide for more 
information about creating an index for performance 

Creating an Index Associated with a Constraint 

Oracle Database enforces a UNIQUE key or PRIMARY KEY integrit\' constraint on a 
table by creating a unique index on the unique kev or primary key. This index is 
automatically created by the database yvhen the constraint is enabled. No action is 
required by you when you issue the CREATE TABLE or ALTER TABLE statement to 
create the index, but vou can optionally specif}' a USING INDEX clause to exercise 
control oyer its creation. This includes both when a constraint is defined and enabled, 
and when a defined but disabled constraint is enabled. 

To enable a UNIQUE or PRIMARY KEY constraint, thus creating an associated index, 
the owner of the table must have a quota for the tablespace intended to contain the 
index, or the UNLIMITED TABLESPACE system privilege. The index associated with a 
constraint alv^favs takes the name of the constraint, unless vou optionally specify 
otherwise. 



Note: An efficient procedure for enabling a constraint that can 
make use of parallelism is described in'Efficient Use of Integrity 
Constraints: A Procedure" on page 16-11. 



Specifying Storage Options for an Index Associated with a Constraint 

You can set the storage options for the indexes associated with UNIQUE and PRIMARY 
KEY constraints using the USING INDEX clause. The following CREATE TABLE 
statement enables a PRIMARY KEY constraint and specifies the storage options of the 
associated index: 

CREATE TABLE emp ( 

erapno HUMBER(5) PRIMARY KEY, age IITEGER) 
EHABLE PRIMARY KEY USIHG IHDEX 
TABLESPACE users; 

Specifying the Index Associated witii a Constraint 

If you require more explicit control over the indexes associated with UNIQUE and 
PRIMARY KEY constraints, the diitabase lets you: 

■ Specify an existing index that the database is to use to enforce the constraint 

■ Specify a CREATE INDEX statement that the database is to use to create the index 
and enforce the constraint 

These options are specified using the USING INDEX clause. The following statements 
present some examples. 

Example 1: 

CREATE TABLE a ( 

al IHT PRIMARY KEY USIHG INDEX (create index ai on a (al) ) ) ; 

Example 2: 

CREA'FE TABLE b( 
bl IHT, 
b2 IHT, 
CONSTRAINT bul UNIQUE {bl, b2 ) 

USIHG IHDEX [create unique index bi on b(bl, b2 ) ) , 
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CONSTRAINT bu2 UHIQUE {b2, bl) USIHG INDEX bi) ; 

Example 3: 

CREATE TABLE c(cl INT, c2 INT) ; 

CREATE INDEX ci OH c (cl, c2 ) ; 

ALTER TABLE c ADD CONSTRAINT cpk PRIMARY KEY (cl) USING INDEX ci; 

If a single statement creates an index with one constraint and also uses that index for 
anotlier constraint, the system will attempt to rearrange the clauses to create the index 
before reusing it. 

See Also: "Managing Integrity Constraints" on page 16-9 

Collecting Incidental Statistics when Creating an Index 

Oracle Database provides vou with the opportunit}" to collect statistics at verv little 
resource cost during the creation or rebuilding of an index. These statistics are stored 
in the data dictionary for ongoing use bv the optimizer in choosing a plan for the 
execution of SQL statements. The following statement computes index, table, and 
column statistics while building index emp_ena.me on column enaine of table emp; 

CREATE INDEX emp_enaine ON einp(eDaine) 
COMPUTE STATISTICS; 

See Also: 

■ Omcif Database Performance Tuning Guide for information about 
collecting statistics and their use bv the optimizer 



"Analyzing Tables, Indexes, and Clusters" on page 16-2 
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When creating an extremely large index, consider allocating a larger temporary 
tablespace for the index creation using the following procedure: 

1. Create a new temporary tablespace using the CREATE TABLESPACE or CREATE 

TEMPORARY TABLESPACE statement, 

2. Use the TEMPORARY TABLESPACE option of the ALTER USER statement to make 
this your new temporary tablespace, 

3. Create the index using the CREATE INDEX statement. 

4. Drop this tablespace using the DROP TABLESPACE statement. Then use the ALTER 
USER statement to reset your temporary tablespace to your original temporary 
tablespace. 

Using this procedure can avoid the problem of expanding your usual, and usually 
shared, temporary tablespace to an unreasonably large size that might affect future 
performance. 



Creating an Index Online 



You can create and rebuild indexes online. This enables vou to update base tables at 
the same time you are building or rebuilding indexes on that table. You can perform 
DML operations while the index build is taking place, but DDL operations are not 
allowed. Parallel execution is not supported when creating or rebuilding an index 
online. 

The following statements illustrate online index buUd operations: 
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CREATE IHDEX emp_name OH emp [mgr, empl, emp2 , emp3) OMLIHE; 

Note: Keep in mind that ttie time that it takes on online index 
build to complete is proportional to the size of the table and the 
number of concurrently executing DML statements. Therefore, it is 
best to start online index builds when DML activity is low. 

See Also: "Rebuilding an Existing Index" on page 19-13 



Creating a Function-Based index 



Function-based indexes facilitate queries that qualify' a value returned bv a function 
or expression. The value of the function or expression is precomputed and stored in 
the index. 

In addition to the prerequisites for creating a conventional index, if the index is based 
on user-defined functions, then those functions must be marked DETERMINISTIC. 
Also, you just have the EXECUTE object privilege on anv user-defined function(s) used 
in the function-based index if those functions are owned by another user. 

Additionallv, to use a function-based index: 

■ The table must be analyzed after the index is created. 

■ The query must be guaranteed not to need anv NULL values from the indexed 
expression, since NULL values are not stored in indexes. 

Note: CREATE INDEX stores the timestamp of the most recent 
function used in the function-based index. This timestamp is 
updated when the index is validated. When performing tablespace 
point-in-time recovery of a function-based index, if the timestamp 
on the most recent function used in the index is newer than the 
timestamp stored in the index, then the index is marked invalid. 

You must use the ANALYZE INDEX. . .VALIDATE STRUCTURE 

statement to validate this index. 



To illustrate a function-based index, consider the following statement that defines a 
function-based index (area_index) defined on the function area (geo) : 

CREATE IHDEX area_index OH rivers (areafgeo}); 

In the following SQL statement, when area ( geo) is referenced in the WHERE clause, 
the optimizer considers using the index area_index. 

SELECT id, geo, area (geo), desc 
FROM rivers 
WHERE Area(geo) >5000r 

Table owners should have EXECUTE privileges on the functions used in 
function-based indexes. 

Because a function-based index depends upon any function it is using, it can be 
invalidated when a function changes. If the function is valid, vou can use an ALTER 
INDEX . . . ENABLE statement to enable a function- based index that has been disabled. 
The ALTER INDEX. . .DISABLE statement lets you disable the use of a function-based 
Index. Consider doing this if you are working on the body of the function. 
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Note: An alternative to creating a function-based index is to add a 
virtual column to the target table and index the virtual column. See 
"About Tables" on page 18-1 for Kiore information. 



See Also: 



Oracle Database Concepts for more information about 
function-based indexes 

Oracle Database Advanced Application Developer's Guide for 
information about using function-based indexes in applications 
and examples of their use 



Creating a Key-Compressed Index 



Creating an index using kev compression enables vou to eliminate repeated 
occurrences of key column prefix values. 

Key compression breaks an index kev into a prefix and a suffix entrv. Compression is 
achieved bv sharing the prefix entries among all the suffix entries in an index block. 
This sharing can lead to huge savings in space, allowing you to store more keys for 
each index block while improving performance. 

Key compression can be useful in the following situations: 

■ You have a non-unique index where ROWID is appended to make the kev unique. 
If vou use kev compression here, the duplicate key is stored as a prefix entry on 
the index block without the ROWID. The remaining rows become suffix entries 
consisting of only the ROWID. 

■ You have a unique multicolumn index. 

You enable key compression using the COMPRESS clause. The prefix length (as the 
number of kev columns) can also be specified to identifv how the key columns are 
broken into a prefix and suffix entry. For example, the following statement compresses 
duplicate occurrences of a key in the index leaf block: 

CREATE IMDEX emp_enanie OH emp(enaine) 
TABLES PACE users 
COMPRESS 1; 

The COMPRESS clause can also be specified during rebuild. For example, during 
rebuild you can disable compression as follows: 

ALTER INDEX emp_ename REBUILD NOCCMPRESS; 

See Also: Oracle Database Concepts for a more detailed discussion 
of kev compression 



Creating an invisible index 



Beginning with Release 11^, vou can create invisible indexes. An invisible index is an 
index that is ignored bv the optimizer unless vou explicitly set the 
OPTIMIZER_USE_INVISIBLE_INDEXES initialization parameter to TRUE atthe 
session or system level. Making an index invisible is an alternative to making it 
unusable or dropping it. Using invisible indexes, vou can do the following: 

■ Test the removal of an index before dropping it. 
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■ Use temporary index structures for certain operations or modules of an 
application without affecting the overall application. 

Unlike unusable indexes, an invisible index is maintained during DML statem.ents. 

To create an invisible index, use the SQL statement CREATE INDEX with the 
INVISIBLE clause. The following statement creates an invisible index named 
einp_enai[ie for the enaine column of the emp table: 

CREATE INDEX erap_ename ON emp[ename) 
TABLES PACE users 
STOKAGE (INITIAL 2 OK 
NEXT 2 0k 
PCTIHCEEA5E 75} 
INVISIBLE; 

See Also: 

■ "Making an Index Invisible" on page 19-14 



Orach' Database SQL Language Reference for information about 
using comments in a SELECT statement to pass hints to the 
Oracle Database optimizer 



Altering Indexes 



To alter an index, your schema must contain the index or you must have the ALTER 
ANY INDEX system privilege. With the ALTER INDEX statement, you can: 

Rebuild or coalesce an existing index 

Deallocate unused space or allocate a new extent 

Specifv parallel execution (or not) and alter the degree of paralleiisna 

Alter storage param.eters or physical attributes 

Specify LOGGING or NOLOGGING 

Enable or disable key compression 

Mark the index unusable 

Make the index invisible 

Start or stop the monitoring of index usage 

You cannot alter index column structure. 

More detailed discussions of some of these operations are contained in the following 
sections: 

■ Altering Storage Characteristics of an Index 

■ RebuUding an Existing Index 

■ Making an Index Invisible 

■ Monitoring Index Usage 

See Also: 

■ Oracle Database SQL Language Rejerence for details on the ALTER 
INDEX statement 
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Altering Storage Characteristics of an Index 

Alter the storage parameters of any index, including those created bv the database to 
enforce primary and unique key integrity constraints, using the ALTER INDEX 
statement. For example, the following statement alters the einp_enaine index: 

ALTER INDEX emp_ename 

STORAGE (PCTIHCREASE 50}; 

The storage parameters INITIAL and MINEXTEHTS cannot be altered. All new 
settings for the other storage parameters affect only extents subsequently allocated for 
the index. 

For indexes that implement integrity constraints, vou can adjust storage parameters by 
issuing an ALTER TABLE statement that includes the USING INDEX subclause of the 
ENABLE clause. For example, the following statement changes the storage options of 
the index created on table emp to enforce the primary key constraint: 

ALTER TABLE emp 

EHRBLE PRIMARY KEY USIHG IHDEX; 

See Also: Oracle Database SQL Language Reference for syntax and 
restrictions on the use of the ALTER INDEX statement 



Rebuilding an Existing Index 



Before rebuilding an existing index, compare the costs and benefits associated with 
rebuilding to those associated with coalescing indexes as described in Table 19-1 on 
page 19-5. 

When 3'ou rebuild an index, you use an existing index as the data source. Creating an 
index in this manner enables you to change storage characteristics or move to a new 
tablespace. Rebuilding an index based on an existing data source removes intra-block 
fragmentation. Compared to dropping the index and using the CREATE INDEX 
statement, re-creating an existing index offers better performance. 

The following statement rebuilds the existing index emp_naine: 

ALTER IHDEX emp_naiiie REBUILD; 

The REBUILD clause must immediately follow the index name, and precede any other 
options. It caruiot be used in conjunction with the DEALLOCATE UNUSED clause. 

You have the option of rebuilding the index online. Rebuilding online enables you to 
update base tables at the same time that you are rebuilding. The following statement 
rebuilds the emp_name index online: 

ALTER INDEX emp_naine REBUILD ONLINE; 



Note: Online index rebuilding has stricter limitations on the 
maximum key length that can be handled, compared to other methods 
of rebuilding an index. If an ORA-1450 (maximum key length 
exceeded) error occurs when rebuilding online, trv rebuilding offhne, 
coalescing, or dropping and recreating the index. 



If you do not have the space required to rebuild an index, you can choose instead to 
coalesce the index. Coalescing an index is an online operation. 
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See Also: 

■ "Creating an Index Online" on page 19-9 

■ "Monitoring Space Use of Indexes" on page 19-14 

Making an Index Invisible 

To make a visible index invisible, issue this statement: 

ALTEH INDEX index IHVISIBLE; 

To make an invisible index visible, issue this statement: 

ALTER INDEX index VISIBLE; 

To find out whether an index is visible or invisible, querv the dictionarv views 
USEE_INDEXES, ALL_IWDEXES, or DBA_INDEXES, For example, to determine if the 
index INDl is invisible, issue the following query: 

SELECT IHDEXJfiME, VISIBILITY BTfOM USER_INDEXES 
WHERE INDEX_NME = ' INDl ' ; 

IHDEX_HfflE VISIBILITY 

INDl VISIBLE 

See Also: "Creating an Invisible Index" on page 19-11 for a 
definition of invisible indexes. 



Monitoring Index Usage 



Oracle Database provides a means of monitoring indexes to determine whether they 
are being used. If an index is not being used, then it can be dropped, eliminating 
unnecessarv statement overhead. 

To start monitoring the usage of an index, issue this statement: 

ALTER INDEX index MOHITORING DSAGE; 

Later, issue the following statement to stop the monitoring: 

ALTER INDEX index NOMONITORIHG USAGE; 

The view V$OBJECT_USAGE can be queried for the index being monitored to see if the 
index has been used. The view contains a USED column whose value is YES or NO, 
depending upon if the index has been used within the time period being monitored. 
The view also contains the start and stop times of the monitoring period, and a 
MONITORING column (yes/no) to indicate if usage monitoring is currently active. 

Each time that you specify MONITORING USAGE, the VSOBJECT_USAGE view is reset 
for the specified index. The previous usage information is cleared or reset, and a new 
start time is recorded. When you specify NOMONITORING USAGE, no further 
monitoring is performed, and the end time is recorded for the monitoring period. 
Until the next ALTER INDEX. . .MONITORING USAGE statement is issued, the view 
information is left unchanged. 



Monitoring Space Use of Indexes 



If key values in an index are inserted, updated, and deleted frequently, the index can 
lose its acquired space efficientiv over time. Monitor index efficiency of space usage at 
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regular intervals bv first analyzing tlie index structure, using the ANALYZE 

INDEX . . . VALIDATE STRUCTURE statement, and then quer}'ing the INDEX_STATS 

view; 

SELECT PCT_USED FROM INDEX_STATS WHERE HME = ' index' ; 

The percentage of index space usage \'aries according to how often index kevs are 
inserted, updated, or deleted. Develop a historv of average efficiency of space usage 
for an index by performing the following sequence of operations several times: 

■ Analyzing statistics 

■ Validating the index 

■ Checking PCT_USED 

■ Dropping and rebuilding (or coalescing) the index 

When you find that index space usage drops below its average, vou can condense the 
index space bv dropping the index and rebuilding it, or coalescing it. 

See Also: "Analyzing Tables, Indexes, and Clusters" on page 16-2 



Dropping Indexes 



To drop an index, the index must be contained in your schema, or you must have the 

DROP ANY INDEX system privilege. 

Some reasons for dropping an index include: 

■ The index is no longer required. 

■ The index is not providing anticipated performance improvements for queries 
issued against the associated table. For example, the table might be very small, or 
there might be manv rows in the table but ver\' few index entries. 

■ Applications do not use the index to query the data. 

■ The index has become invalid and must be dropped before being rebuilt, 

■ The index has become too fragmented and must be droppied before being rebuUt. 

When you drop an index, all extents of the index segment are returned to the 
containing tablespace and become available for other objects in the tablespace. 

How you drop an index depends on whether you created the index explicitly with a 
CREATE INDEX statement, or implicitiv by defining a key constraint on a table. If you 
created the index explicitly with the CREATE INDEX statement, then you can drop the 
index with the DROP INDEX statement. The following statement drops the 
einp_enaine index: 

DROP INDEX emp_enaiiie; 

You cannot drop only the index associated with an enabled UNIQUE key or PRIMARY 
KEY constraint. To drop a constraints associated index, you must disable or drop the 
constraint itself. 



Note: If a table is dropped, all associated indexes are dropped 
automatically. 
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See Also: 



Orack' Database SQL Language Reference for svntax and 
restrictions on the use of the DROP INDEX statement 

"Managing Integrity Constraints" on page 16-9 

"Making an Index Invisible" on page 19-14 for an alternative to 
dropping indexes 



Indexes Data Dictionary Views 



The following views display information about indexes: 



View 



Description 



DBA_im)EXE3 

ALL_IHDEXES 
DSER_IHDEXES 
DBA_IHD_COLUMNS 
ALL_IHD_COLUMNS 
USER IND COLUMHS 



DBA view describes indexes on all tables in the database. ALL view describes 
indexes on all tables accessible to the user, USEE view is restricted to indexes 
owned by the user Some columns in these views contain statistics that are 
generated by the DBMS_STATS package or AMALYZE statement. 

These views describe the columns of indexes on tables. Some columns in these 
views contain statistics that are generated bv the DBMS_STATS package or 
ANALYZE statement. 



DBA_IHD_EXPRES S lOHS 
ALL_IHD_EXPRESSIOHS 
USER IND EXPRESSIOWS 



These views describe the expressions of lh.inction-based indexes on tables. 



DBA_IHD_STATISTICS 
ALL_IHD_STATISTICS 
USER IND STATISTICS 



These views contain optimizer statistics for indexes. 



INDEX STATS 



INDEX HISTOGRAM 



VSOBJECT_USAGE 



Stores information from the last ANALYZE INDEX .. .VALIDATE STRUCTURE 
statement. 

Stores information from the last ANALYZE INDEX .. .VALIDATE STRUCTURE 
statement. 

Contains index usage information produced by the ALTER 
INDEX. . .MONITORING USAGE functionality 



See Also: Oracle Database Reference for a complete description of 
these views 
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Managing Clusters 



In this chapter: 

About Clusters 

Guidehnes for Managing Clusters 

Creating Clusters 

Altering Ckisters 

Dropping Clusters 

Clusters Data Dictionary Views 



About Clusters 



A cluster provides an optional method of storing table data. A cluster is made up of a 
group of tables that share the same data blocks. The tables are grouped together 
because they share common columns and are often used together For example, the 
emp and dept table share the deptno column. When vou cluster the emp and dept 
tiibles (see Figure 20-1), Oracle Database physically stores all rows for each 
department from both the emp and dept tables in the same data blocks. 

Because clusters store related rows of different tables together in the same data blocks, 
properly used clusters offer two primary benefits: 

■ Disk I/O is reduced and access time improyes for joins of clustered tables, 

■ The cluster key is the column, or group of columns, that the clustered tables haye 
in common. You specify the columns of the cluster key when creating the cluster. 
You subsequently specif\' the same columns when creating eyery table added to 
the cluster. Each cluster key \'alue is stored only once each in the cluster and the 
cluster index, no matter hoyi' many rows of different tables contain the yalue. 

Therefore, less storage might be required to store related table and index data in a 
cluster than is necessary in non-clustered table format For example, in 
Figure 20-1, notice hov^f each cluster key (each deptno) is stored just once for 
many rows that contain the same yalue in both the emp and dept tables. 

After creating a cluster, you can create tables in the cluster Howeyer, before any rows 
can be inserted into the clustered tables, a cluster index must be created. Using clusters 
does not affect the creation of additional indexes on the clustered tables; they can be 
created and dropped as usual. 

You should not use clusters for tables that are frequently accessed indiyidually. 
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Figure 20-1 Clustered Table Data 
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together, more 
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UnclusteredTables 
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See Also: 



Chapter 21, "Managing Hash Ckisters" for a description of 
anotlier t\'pe of cluster: a hash cluster 

Chapter 17, "Managing Space for Scliema Objects" is 
recommended reading before attempting tasks described in 
this chapter 



Guidelines for Managing Clusters 



The following sections describe guideUnes to consider when managing clusters, and 
contains the following topics; 
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Choose Appropriate Tables for the Ckister 

Choose Appropriate Coiumns for the Cluster Key 

Specify the Space Required hv an Average Cluster Kev and Its Associated Rows 

Specif}' the Location of Each Cluster and Cluster Index Rows 

Estimate Cluster Size and Set Storage Parameters 

See Also: 

■ Oracle Database Concepts for more information about clusters 

■ Oracle Database Performance Timing Guide for guidelines on 
when to use clusters 

Choose Appropriate Tables for the Cluster 

Use clusters for tables for which the following conditions are true: 

■ The tables are primarily queried— that is, tables that are not predominantly inserted 
into or updated, 

■ Records from the tables are frequently queried together or joined. 

Choose Appropriate Columns for the Cluster Key 

Choose cluster kev columns carefuUv, If multiple columns are used in queries that join 
the tables, make the cluster kev a composite key. In general, the characteristics that 
indicate a good cluster index are the same as those for any index. For information 
about characteristics of a good index, see "Guidelines for Managing Indexes" on 
page 19-2. 

A good cluster key has enough unique values so that the group of rows corresponding 
to each key value fills approximately one data block. Having too few rows for each 
cluster key value can waste space and result in negligible performance gains. Cluster 
keys that are so specific that onlv a few rows share a common value can cause wasted 
space in blocks, unless a small SIZE was specified at cluster creation time (see "Specify 
the Space Required bv an Average Cluster Key and Its Associated Rows" on 
page 20-3). 

Too manv rows for each cluster key value can cause extra searching to find rows for 
that kev. Cluster kevs on values that are too general (for example, male and female) 
result in excessive searching and can result in worse performance than with no 
clustering. 

A cluster index cannot be unique or include a column defined as long. 

Specify the Space Required by an Average Cluster Key and Its Associated Rows 

The CREATE CLUSTER statement has an optional clause, SIZE, which is the estimated 
number of bytes required b\' an average cluster key and its associated rows. The 
database uses the SIZE parameter when performing the following tasks: 

■ Estimating the number of cluster keys (and associated rows) that can fit in a 
clustered data block 

■ Limiting the number of cluster kevs placed in a clustered data block. This 
maximizes the storage efficiency of keys within a cluster 
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SI ZE does not limit the space that can be used by a given cluster key. For example, if 
31 ZE is set such that two cluster kevs can fit in one data block, anv amount of the 
available data block space can still be used by either of the cluster keys. 

By default, the database stores only one cluster key and its associated rows in each 
data block of the cluster data segment. Although block size can vary from one 
operating system to the next, the rule of one key for each block is maintained as 
clustered tables are imported to other databases on other machines. 

If all the rows for a given cluster key value cannot fit in one block, the blocks are 
chained together to speed access to all the values with the given key. The cluster index 
points to the beginning of the chain of blocks, each of which contains the cluster key 
value and associated rows. If the cluster SIZE is such that more than one key fits in a 
block, blocks can belong to more than one chain. 

Specify the Location of Each Cluster and Cluster Index Rows 

If you have the proper privileges and tablespace quota, vou can create a new cluster 
and the associated cluster index in anv tablespace that is currently online. Always 
specify the TABLESPACE clause in a CREATE CLUSTER/IHDEX statement to identify 
the tablespace to store the new cluster or index. 

The cluster and its cluster index can be created in different tablespaces. In fact, creating 
a cluster and its index in different tablespaces that are stored on different storage 
devices allows table data and index data to be retrieved simultaneously with minimal 
disk contention. 

Estimate Cluster Size and Set Storage Parameters 

The following are benefits of estimating cluster size before creating the cluster: 

■ You can use the combined estimated size of clusters, along with estimates for 
indexes and redo log files, to determine the amount of disk space that is required 
to hold an intended database. From these estimates, you can make correct 
hardware purchases and other decisions, 

■ You can use the estimated size of an individual cluster to better manage the disk 
space that the cluster will use. When a cluster is created, you can set appropriate 
storage parameters and improve I/O performance of applications that use the 
cluster. 

Whether or not you estimate table size before creation, you can explicitly set storage 
parameters when creating each nonclustered table. Any storage parameter that you do 
not explicitly set when creating or subsequently altering a table automatically uses the 
corresponding default storage parameter set for the tablespace in which the table 
resides. Clustered tables also automatically use the storage parameters of the cluster. 



Creating Clusters 



To create a cluster in vour schema, vou must have the CREATE CLUSTER system 
privilege and a quota for the tablespace intended to contain the cluster or the 

UNLIMITED TABLESPACE system privilege. 

To create a cluster in another user's schema you must have the CREATE ANY 
CLUSTER system privilege, and the owner must have a quota for the tablespace 
intended to contain the cluster or the UNLIMITED TABLESPACE system privilege. 
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YoLL create a cluster using the CREATE CLUSTER statement. The following statement 
creates a cluster named emp_dept, which stores the emp and dept tables, clustered 
by the deptno column: 

CREATE CLUSTER emp_dept {deptno HIMBER{3)| 
SIZE 600 

TABLES PACE users 
STORAGE (INITIAL 200K 

NEXT 300K 

MIHEXTENTS 2 

MAXEXTENTS 2 

PCTINCREASE 33}; 

If no INDEX keyword is specified, as is true in this example, an index cluster is created 
by default. You can also create a HASH cluster, when hash parameters (HASHKEYS, 
HASH IS,orSIHGLE TABLE HASHKEYS) are specified. Hash clusters are described in 
Chapter 21, "Managing Hash Clusters", 



Creating Clustered Tables 



To create a table in a cluster, you must have either the CREATE TABLE or CREATE 
AHY TABLE svstem privilege. You do not need a tablespace quota or the UMLIMITED 
TABLESPACE system privilege to create a table in a cluster. 

You create a table in a cluster using the CREATE TABLE statement with the CLUSTER 
clause. The emp and dept tables can be created in the emp_dept cluster using the 
following statements: 

CREATE TABLE emp ( 

empno MUMBER(5) PRIMARY KEY, 
enanie VARCHAR2(15} NOT NULL, 

deptno NTMBER{3) REFERENCES dept) 
CLUSTER emp_dept (deptno); 

CREATE TABLE dept ( 

deptno NnMBER{3) PRIMARY KEY, . . . ) 
CLUSTER emp_dept (deptno); 

Note: You can specify the schema for a clustered table in the 
CREATE TABLE statement A clustered table can be in a different 
schema than the schema containing the cluster Also, the names of 
the columns are not required to match, but their structure must 
match. 



See Also: Oracle Database SQL Language Rcfercna for syntax of the 
CREATE TABLE statement for creating cluster tables 

Creating Cluster Indexes 

To create a cluster index, one of the following conditions must be true: 

■ Your schema contains the cluster. 

■ You have the CREATE AHY INDEX system privilege. 

In either case, vou must also have either a quota for the tablespace intended to contain 
the cluster index, or the UNLIMITED TABLESPACE system privilege. 
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A cluster index must be created before any rows can be inserted into any clustered 
table. The following statement creates a cluster index for the emp_dept cluster: 

(CREATE IHDEX emp_dept_index 
OH CLUSTER eni)_dept 
TABLES PACE users 
STORAGE (INITIAL 50K 

NEXT 5 OK 

MIHEXTENTS 2 

MAXEXTENTS 10 

PCTINCREASE 33}; 

The cluster index clause (ON CLUSTER) identifies the cluster, emp_dept, for which 
the cluster index is being created. The statement also explicitly specifies se\'eral 
storage settings for the cluster and cluster index. 

See Also: Oracle Database SQL Language Reference for syntax of the 
CREATE INDEX statement for creating cluster indexes 



Altering Clusters 



To alter a cluster, your schema must contain the cluster or you must have the ALTER 
ANY CLUSTER svstem privilege. You can alter an existing cluster to change the 
following settings: 

■ Physical attributes (INITRANS and storage characteristics) 

■ The average amount of space required to store all the rows for a cluster kev value 
(SIZE) 

■ The default degree of parallelism 

Additionally, vou can explicitiv allocate a new extent for the cluster, or deallocate any 
unused extents at the end of the cluster The database dynamically allocates additional 
extents for the data segment of a cluster as required. In some circumstances, however, 
you might want to explicitly allocate an additional extent for a cluster. For example, 
when using Real Application Clusters, vou can allocate an extent of a cluster explicitly 
for a specific instance. You allocate a new extent for a cluster using the ALTER 
CLUSTER statement with the ALLOCATE EXTENT clause. 

When you alter the cluster size parameter (SIZE) of a cluster, the new settings apply 
to all data blocks used by the cluster, including blocks alreadv allocated and blocks 
subsequently allocated for the cluster Blocks already allocated for the table are 
reorganized when necessary (not immediatelv). 

When you alter the transaction entrv setting INITRANS of a cluster, the new setting for 
INITRANS applies only to data blocks subsequently allocated for the cluster. 

The storage parameters INITIAL and MINEXTENTS cannot be altered. All new 
settings for the other storage parameters affect onlv extents subsequently allocated for 
the cluster. 

To alter a cluster, use the ALTER CLUSTER statement. 

See Also: Oracle Database SQL Language Reference for syntax of the 

ALTER CLUSTER statement 



Altering Clustered Tables 



You can alter clustered tables using the ALTER TABLE statement. However, any data 
block space parameters, transaction entry parameters, or storage parameters vou set in 
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an ALTER TABLE statement for a clustered table generate an error message 
(ORA-Omi , illegal option for a clustered table). The database uses 
the parameters of the cluster for all clustered tables. Therefore, you can use the ALTER 
TABLE statement only to add or modify columns, drop non-cluster- key columns, or 
add, drop, enable, or disable integrity' constraints or triggers for a clustered table. For 
information about altering tables, see "Altering Tables" on page 18-20, 

See Also: Oracle Database SQL Language Reference for syntax of the 
ALTER TABLE statement 



Altering Cluster Indexes 



You alter cluster indexes exactly as vou do other indexes. See "Altering Indexes" on 
page 19-12. 

Note: When estimating the size of cluster indexes, remember that 
the index is on each cluster key, not the actual rows. Therefore, 
each key appears only once in the index. 



Dropping Clusters 



A cluster can be dropped if the tables within the cluster are no longer needed. When a 
cluster is dropped, so are the tables within the cluster and the corresponding cluster 
index. All extents belonging to both the cluster data segment and the index segment of 
the cluster index are returned to the containing tablespace and become available for 
other segments within the tablespace. 

To drop a cluster that contains no tables, and its cluster index, use the DROP CLUSTER 
statement. For example, the following statement drops the empty cluster named 

emp_dept: 

DROP CLUSTER emp_deptr 

If the cluster contains one or more clustered tables and you intend to drop the tables as 

weU, add the INCLUDING TABLES clause of the DROP CLUSTER statement, as 
follows: 

DROP CLUSTER emp_dept IHCLUDItJG TABLES ; 

If the INCLUDING TABLES clause is not included and the cluster contains tables, an 
error is returned. 

If one or more tables in a cluster contain primar\" or unique keys that are referenced bv 
FOREIGN KEY constraints of tables outside the cluster, the cluster cannot be dropped 
unless the dependent FOREIGN KEY constraints are also dropped. This can be easily 
done using the CASCADE CONSTRAINTS clause of the DROP CLUSTER statement, as 
shown in the following example: 

DROP CLUSTER emp_dept IHCLUDIHG TABLES CASCADE CONSTRAINTS; 

The database returns an error if you do not use the CASCADE CONSTRAINTS clause 
and constraints exist. 

See Also: Oracle Database SQL Language Reference for syntax of the 

DROP CLUSTER statement 
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Dropping Clustered Tables 

To drop a cluster, your schema must contain the cluster or you must have the DROP 
AMY CLUSTER svstem privilege. You do not need additional privileges to drop a 
cluster that contains tables, even if the clustered tables are not owned by the owner of 
the cluster. 

Clustered tables can be dropped individually without affecting the cluster, other 
clustered tables, or the cluster index, A clustered table is dropped just as a 
nonclustered table is dropped, with the DROP TABLE statement. See "Dropping Table 
Columns" on page 18-24. 



Note: When you drop a single table from a cluster, the database 
deletes each row of the table individually. To maximize efficiencv 
v^fhen vou intend to drop an entire cluster, drop the cluster 
including all tables by using the DROP CLUSTER statement with 
the INCLUDING TABLES clause. Drop an individual table from a 
cluster (using the DROP TABLE statement) onlv if vou want the rest 
of the cluster to remain. 

Dropping Cluster Indexes 

A cluster index can be dropped without affecting the cluster or its clustered tables. 
However, clustered tables cannot be used if there is no cluster index; you must 
re-create the cluster index to allow access to the cluster Cluster indexes are sometimes 
dropped as part of the procedure to rebuild a fragmented cluster index. For 
information about dropping an index, see "Dropping Indexes ' on page 19-15. 

Clusters Data Dictionary Views 

The follow^ing views display information about clusters: 
View Description 



DBA_CLUSTERS DBA view describes all clusters in the database. ALL view describes all clusters 

accessible to the user. USER view is restricted to clusters owned by the user 
Some cohimns in these views contain statistics that are generated by the 
DSER_CLUSTERS DBHS_STATS package orAHALYZE statement. 



ALL CLUSTERS 



DBA_CLU_COLUHN'S These views map table columns to cluster columns 

USER CLU COLUMHS 



See Also: Oracle Database Referenee for complete descriptions of 
these views 
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In this chapter; 

About Hash Clusters 

When to Use Hash Clusters 

Creating Hash Clusters 

Altering Hash Clusters 

Dropping Hash Clusters 

Hash Clusters Data Dictionan' Views 



About Hash Clusters 



storing a table in a hash cluster is an optional ivav to improve the performance of data 
retrieval. A hash cluster provides an alternative to a non-clustered table with an index 
or an index cluster With an indexed table or index cluster, Oracle Database locates the 
rows in a table using key values that the database stores in a separate index. To use 
hashing, vou create a hash cluster and load tables into it. The database physically 
stores the rows of a table in a hash cluster and retrieves them, according to the results 
of a hash function, 

Oracle Database uses a hash function to generate a distribution of numeric values, 
called hash values, that are based on specific cluster kev values. The kev of a hash 
cluster, like the kev of an index cluster, can be a single column or composite kev 
(multiple column key). To find or store a row in a hash cluster, the database applies 
the hash function to the cluster key value of the row. The resulting hash value 
corresponds to a data block in the cluster, which the database then reads or writes on 
behalf of the issued statement. 

To find or store a row in an indexed table or cluster, a minimum of two (there are 
usuallv more) 1/Os must be performed: 

■ One or more I/Os to find or store the kev value in the index 

■ Another I/O to read or write the row in the table or cluster 

In contrast, the database uses a hash function to locate a row in a hash cluster; no I/O 
is required. As a result, a minimum of one I/O operation is necessarv to read or write 
a row in a hash cluster 

See Also: Chapter 17, "Managing Space for Schema Objects" is 
recommended reading before attempting tasks described in this 
chapter. 
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When to Use Hash Clusters 

This section helps vou decide when to use hash clusters bv contrasting situations 
where hashing is most useful against situations where there is no advantage. If you 
find vour decision is to use indexing rather than hashing, then you should consider 
whether to store a table individuallv or as part of a cluster. 

Note: Even if you decide to use hashing, a table can still have 
separate indexes on any columns, including the cluster key. 

Situations Wliere Hashing Is Useful 

Hashing is useful when you have the following conditions: 

■ Most queries are equalitv queries on the cluster key: 

SELECT ... WHERE cluster_key = ...; 

In such cases, the cluster kev in the equality' condition is hashed, and the 
corresponding hash key is usuallv found with a single read. In comparison, for an 
indexed table the key value must first be found in the index (usuallv several 
reads), and then the row is read from the table (another read), 

■ The tables in the hash cluster are primarily static in size so that you can determine 
the number of rows and amount of space required for the tables in the cluster. If 
tables in a hash cluster require more space than the initial allocation for the cluster, 
performance degradation can be substantial because overflow blocks are required. 

Situations Where Hashing Is Not Advantageous 

Hashing is not advantageous in the following situations: 

■ Most queries on the table retrieve rows over a range of cluster key values. For 
example, in full table scans or queries such as the following, a hash function 
cannot be used to determine the location of specific hash keys. Instead, the 
equivalent of a full table scan must be done to fetch the rows for the query, 

SELECT . , . WHERE cluster_key < . . . ; 

With an index, key values are ordered in the index, so cluster key values that 
satisfy the WHERE clause of a query can be found with relatively few I/Os, 

■ The table is not static, but instead is continually growing. If a table grows without 
limit, the space required over the life of the table (its cluster) cannot be 
predetermined, 

■ Applications frequently perform full-table scans on the table and the table is 
sparsely populated, A full-table scan in this situation takes longer under hashing, 

■ You cannot afford to preallocate the space that the hash cluster will eventually 
need. 
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A hash cluster is created using a CREATE CLUSTER statement, but you specify a 
HASHKEYS clause. The following example contains a statement to create a cluster 
named trial_c luster that stores the trial table, clustered by the trialno 
column (the cluster key); and another statement creating a table in the cluster. 
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CREATE CLUSTER trial_cluster [trialno mMBER[5,0)] 
TABLESPACE users 

STORAGE (IHITIAL 250K NEXT 50K 

MIHEXTENTS 1 MAXEXTEHTS 3 

PCTIHCEEASE 0) 
HASH IS trialno HASHKEYS ISC- 
CREATE TABLE trial ( 

trialno HUHBER(5,0] PRIMARY KEY", 

CLUSTER trial_cluster (trialno); 

As with index clusters, the key of a hash cluster can be a single column or a composite 
key (multiple column key). In this example, it is a single column. 

The HASHKEYS value, in this case 150, specifies and limits the number of unique hash 
values that can be generated by the hash function used bv the cluster. The database 
rounds the number specified to the nearest prime number 

If no HASH IS clause is specified, the database uses an internal hash function. If the 
cluster key is alreadv a unique identifier that is uniformly distributed over its range, 
you can bypass the internal hash function and specify the cluster key as the hash 
value, as is the case in the preceding example. You can also use the HASH IS clause to 
specify a user- defined hash function. 

You cannot create a cluster index on a hash cluster, and you need not create an index 
on a hash cluster key. 

For additional information about creating tables in a cluster, guidelines for setting 
parameters of the CREATE CLUSTER statement common to index and hash clusters, 
and the privileges required to create any cluster, see Chapter 20, "Managing Clusters". 
The following sections explain and provide guidelines for setting the parameters of the 
CREATE CLUSTER statement specific to hash clusters: 

■ Creating a Sorted Hash Cluster 

■ Creating Single-Table Hash Clusters 

■ Controlling Space Use Within a Hash Cluster 

■ Estimating Size Required by Hash Clusters 
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In a sorted hash cluster, the rows corresponding to each value of the hash function are 
sorted on a specified set of columns in ascending order, which can improve response 
time during subsequent operations on the clustered data. 

For example, a telecommunications company needs to store detailed call records for a 
fixed number of originating telephone numbers through a telecommunications switch. 
From each originating telephone number there can be an unlimited number of 
telephone calls. 

Calls are stored as they are made and processed later in first-in, first-out order (FIFO) 
yvhen bills are generated for each originating telephone number Each call has a 
detailed call record that is identified by a timestamp. The data that is gathered is 
similar to the following: 

Originating Telephone Numliers Call Records Identified by Timestamp 



650-555-1212 tO, tl, t2, t3, t4, ... 
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Originating Telephone Numbers Call Records Identified by Timestamp 



650-555-1213 tO, tl, ^2, ^3, t4, ... 

650-555-1214 tO, tl, t2, t3, t4, ... 



In the following SQL statements, the telephone_nuirtber column is the hash key. 
The hash cluster is sorted on the call_tim.es tamp and call_duration columns. 
The number of hash keys is based on 10-digit telephone numbers. 

C3?EATE CLUSTER call_detail_c luster { 

telephorie_number MUMBER, 

call_timestaiirp HUMBER SORT, 

call_duration NUMBER SORT ) 
HASHKEYS 10000 HASH IS telephorie_number 
SIZE 2 55; 

CREATE TftBLE call_detail ( 

telephone_number NUMBER, 

call_times tamp MUMBER SORT , 

calLduration NUMBER SORT, 

other_irifo VARCHAR2(30) ] 

CLUSTER call_detail_cluEter ( 
telephorie_number , call_timestainp, call_duration ); 

Gi\'en the sort order of the data, the following quer}' would return the call records for 
a specified hash kev by oldest record first. 

SELECT ' WHERE telephone_number = 6505551212; 

Creating Single-Table Hash Clusters 

You can also create a single-table hash cluster, which provides fast access to rows in a 
table. However, this table must be the only table in the hash cluster. Essentially, there 
must be a one-to-one mapping betiveen hash keys and data rows. The following 
statement creates a single-table hash cluster named peanut with the cluster key 

variety: 

CREATE CLUSTER peanut (variety HUMBER] 
SIZE 512 SINGLE TABLE HASHKEYS 500; 

The database rounds the HASHKEYS value up to the nearest prime number, so this 
cluster has a maximum of 503 hash key values, each of size 512 bvtes. The SINGLE 
TABLE clause is valid onlv for hash clusters, HASHKEYS must also be specified. 

See Also: Oracle Database SQL Language Reference for the syntax of 
the CREATE CLUSTER statement 

Controlling Space Use Within a Hash Cluster 

When creating a hash cluster, it is important to choose the cluster key correctlv and set 
the HASH IS, SIZE, and HASHKEYS parameters so that performance and space use are 
optimal. The following guidelines describe how to set these parameters. 

Choosing the Key 

Choosing the correct cluster key is depiendent on the most common t}'pes of queries 
issued against the clustered tables. For example, consider the emp table in a hash 
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cluster. If queries often select rows by employee number, the empno column should be 
the cluster key. If queries often select rows by department number, the deptno 
column should be the cluster key. For hash clusters that contain a single table, the 
cluster key is typically the entire primar}' key of the contained table. 

The key of a hash cluster, like that of an index cluster, can be a single column or a 
composite kev (multiple column key). A hash cluster with a composite kev must use 
the internal hash function of the database. 

Setting HASH IS 

Specify the HASH I S parameter only if the cluster key is a single column of the 
NUMBER datatype, and contains uniformly distributed integers. If these conditions 
apply, you can distribute rows in the cluster so that each unique cluster key value 
hashes, with no collisions (two cluster kev values having the same hash value), to a 
unique hash value. If these conditions do not apply, omit this clause so that you use 
the internal hash function. 

Setting SIZE 

SI ZE should be set to the average amount of space required to hold all rows for any 
given hash key. Therefore, to properlv determine SIZE, you must be aware of the 
characteristics of your data: 

■ If the hash cluster is to contain only a single table and the hash key values of the 
rows in that table are unique (one row for each value), SIZE can be set to the 
average row size in the cluster 

■ If the hash cluster is to contain multiple tables, SI ZE can be set to the average 
amount of space required to hold all rows associated with a representative hash 
value. 

Further, once you have determined a (preliminary) value for SIZE, consider the 
following. If the SIZE value is small (more than four hash keys can be assigned for 
each data block) you can use this value for SIZE in the CREATE CLUSTER statement. 
However, if the value of SIZE is large (four or fewer hash keys can be assigned for 
each data block), then you should also consider the expected frequency of collisions 
and whether performance of data retrieval or efficiency of space usage is more 
important to vou. 

■ If the hash cluster does not use the internal hash function (if you specified HASH 
I S) and you expect few or no collisions, you can use your preliminary value of 
SI ZE. No collisions occur and space is used as efficiently as possible. 

■ If vou expect frequent collisions on inserts, the likelihood of overflow blocks being 
allocated to store rows is high. To reduce the possibility' of overflow blocks and 
maximize performance when collisions are frequent, vou should adjust SIZE as 
shown in the following chart. 

Available Space for each Block/ 

Calculated SIZE Setting for SIZE 

1 SIZE 

2 SIZE + 15% 

3 SIZE + 12% 

4 SIZE + 8% 
>4 SIZE 
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Overestimating the value of SIZE increases the amount of unused space in the 
cluster If space efficiency is more important than the performance of data 
retrieval, disregard the adjustments shown in the preceding table and use the 
original value for SIZE. 

Setting HASHKEYS 

For maximum distribution of rows in a hash cluster, the database rounds the 
HASHKEYS value up to the nearest prime number 

Controlling Space in Hash Clusters 

The following examples show how to correctly choose the cluster key and set the HASH 
IS, SI ZE, and HASHKEYS parameters. For all examples, assume that the data block 
size is 2K and that on average, 1950 bvtes of each block is available data space (block 
size minus overhead). 

Controlling Space in Hash Clusters: Example 1 You decide to load the emp table into a 
hash cluster Most queries retrieve emplovee records bv their employee number You 
estimate that the maximum number of rows in the emp table at anv given time is 10000 
and that the average row size is 55 bytes. 

In this case, empno should be the cluster kev. Because this column contains integers 
that are unique, the internal hash function can be bvpassed. SIZE can be set to the 
average row size, 55 bvtes. Note that 34 hash keys are assigned for each data block. 
HASHKEYS can be set to the number of rows in the table, 10000. The database rounds 
this value up to the next highest prime number: 10007. 

CREATE CLUSTER emp_cluEter {empno 
HUMBER) 

SIZE 55 

HASH IS empno HftSHKEYS 10000; 

Controlling Space in Hash Clusters: Example 2 Conditions similar to the previous example 
exist. In this case, however, rows are usuallv retrieved bv department number. At 
most, there are 1000 departments with an average of 10 emplovees for each 
department. Department numbers increment by 10 (0, 10, 20, 30, , . , ). 

In this case, deptno should be the cluster kev. Since this column contains integers that 
are uniformly distributed, the internal hash function can be bvpassed, A preliminarv 
value of SIZE (the average amount of space required to hold all rows for each 
department) is 55 bvtes * 10, or 550 bytes. Using this value for SI ZE, only three hash 
kevs can be assigned for each data block. If vou expect some collisions and want 
maximum performance of data retrieval, slightlv alter vour estimated SIZE to prevent 
collisions from requiring overflow blocks, Bv adjusting SIZE bv IZ"!), to 620 bvtes 
(refer to "Setting SIZE" on page 21-5), there is more space for rows from expected 
collisions, 

HASHKEYS can be set to the number of unique department numbers, 1000, The 
database rounds this value up to the next highest prime number; 1009, 

CREATE CLUSTER aDp_cluster (deptno NUMBER) 

SIZE 520 

HASH IS deptno HASHKEYS 1000; 
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Estimating Size Required by Hash Clusters 

As with index clusters, it is important to estimate the storage required for the data in a 
hash cluster 

Oracle Database guarantees that the initial allocation of space is sufficient to store the 
hash table according to the settings SI ZE and HASHKEYS. If settings for the storage 
parameters INITIAL, HEXT, and MINEXTENTS do not account for the hash table size, 
incremental (additional) extents are allocated until at least SIZE*HASHKEYS is 
reached. For example, assume that the data block size is 2K, the available data space 
for each block is approximately 1900 bytes (data block size minus overhead), and that 
the STORAGE and HASH parameters are specified in the CREATE CLUSTER statement 
as follows: 

STORAGE (INITIAL lOOK 

NEXT 150K 

MINEXTENT3 1 

PCTIMCREASE 0} 
SIZE 1500 
HASHKEYS 100 

In this example, onlv one hash kev can be assigned for each data block. Therefore, the 
initial space required for the hash cluster is at least lOO'ZK or 200K, The settings for the 
storage parameters do not account for this requirement Therefore, an Initial extent of 
lOOK and a second extent of 150K are allocated to the hash cluster 

Alternatively, assume the HASH parameters are specified as follows: 

SIZE 500 HASHKEYS 100 

In this case, three hash kevs are assigned to each data block. Therefore, the initial space 
required for the hash cluster is at least 34'*2K or 68K, The initial settings for the storage 
parameters are sufficient for this requirement (an initial extent of lOOK is allocated to 
the hash cluster). 

Altering Hash Clusters 

You can alter a hash cluster with the ALTER CLUSTER statement 

ALTER CLUSTER einp_dept . . . ; 

The implications for altering a hash cluster are identical to those for altering an index 
cluster, described in "Altering Clusters" on page 20-6. However, the SIZE, HASHKEYS, 
and HASH I S parameters cannot be specified in an ALTER CLUSTER statement. To 
change these parameters, you must re-create the cluster, then copy the data from the 
original cluster 

Dropping Hash Clusters 

You can drop a hash cluster using the DROP CLUSTER statement 
DROP CLUSTER emp_deptr 

A table in a hash cluster is dropped using the DROP TABLE statement The 
implications of dropping hash clusters and tables in hash clusters are the same as 
those for dropping index clusters. 

See Also: "Dropping Clusters" on page 20-7 
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Hash Clusters Data Dictionary Views 

The followmg views display information about hash clusters: 



View Description 


DBA_CLUS'i'l!!KS DBA view describes all clusters (including hash clusters) in the 1 

database. ALL view describes all clusters accessible to the user 
~ DSER view is restricted to clusters owned by the user Some 

USER_CLUSTERS columns in these views contain statistics that are generated by the 

DBMS_STAT3 package or AMALYZE statement 


DBA_CLU_COLUHN'S . These views map table columns to cluster columns. 
DSER_CLU_COLUMHS 


DBA_CLUSTER_HASH_EXPRESSIOHS 
ALL_CLUS'i'ER_HA3H_EXPRES3IOtTS 
USER_CLUSTER_HASH_EXPRESSIOHS 


These views list hash functions for hash clusters. 



See Also: Oracle Database Reference for complete descriptions of 
these views 



21-8 Oracle Database Administrator's Guide 



22 

Managing Views, Sequences, and Synonyms 



In this chapter: 

■ Managing Views 

■ Managing Sequences 

■ Managing Synonyms 

■ Views, Synonyms, and Sequences Data Dictionary Views 

Managing Views 

This section describes aspects of managing views, and contains the following topics: 
About Views 
Creating Views 
Replacing Views 
Using Views in Queries 
Updating a Join View 
Altering Views 
Dropping Views 

About Views 

A view is a logical representation of another table or combination of tables. A view 
derives its data from the tables on which it is based. These tables are called base 
tables. Base tables might in turn be actual tables or might be views themselves. All 
operations performed on a view actually affect the base table of the view. You can use 
view^s in almost the same way as tables. You can query, update, insert into, and delete 
from views, just as you can standard tables. 

Views can provide a different representation (such as subsets or supersets) of the data 
that resides within other tables and views. Views are ver\' powerful because they 
allow you to tailor the presentation of data to different types of users. 

See Also: Oracle Database Concepts for a more complete 
description of views 

Creating Views 

To create a view, you must meet the following requirements: 
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■ To create a view in vour schema, vou must have the CREATE VIEW privilege. To 
create a view in another user's schema, you must have the CREATE ANY VIEW 
system privilege. You can acquire these privileges explicitlv or through a role, 

■ The owner of the view (whether it is vou or another user) must have been 
explicitly granted privileges to access all objects referenced in the view definition. 
The owner camiof have obtained these privileges through roles. Also, the 
functionalitv of the view depends on the privileges of the view owner For 
example, if the owner of the view has only the INSERT privilege for Scott's emp 
table, then the \'iew can be used only to insert new rows into the emp table, not to 

SELECT, UPDATE, or DELETE rows, 

■ If the owner of the \'iew intends to grant access to the view to other users, the 
owner must have received the object privileges to the base objects with the GRANT 
OPTION or the system privileges with the ADMIN OPTION. 

You can create views using the CREATE VIEW statement. Each view is defined bv a 
query that references tables, materialized views, or other views. As with all 
subqueries, the query that defines a view cannot contain the FOR UPDATE clause. 

The following statement creates a view on a subset of data in the emp table: 

CREATE Mim sales_Etaff AS 

SELECT erapno, ename, deptno 
FROM emp 

WHERE deptno = 10 
WITH CHECK OPTION CONSTRAIHT sales_staEf_cnstr 

The query that defines the sales_staff view references only rows in department 10. 
Furthermore, the CHECK OPTION creates the view with the constraint (named 
sales_staf f _cnst) that INSERT and UPDATE statements issued against the view 
cannot result in rows that the view cannot select. For example, the following INSERT 
statement successfully inserts a row into the emp table by means of the sales_staff 
view, which contains all rows with department number 10: 

IH3EET IHTO sales_staff VALUES {7584, ' OSTER ' , 10); 

However, the following INSERT statement returns an error because it attempts to 
insert a row for department number 30, which cannot be selected using the 

3ale3_3taf f view: 

IHSEET IHTO sales_Etaff VALUES {7591, 'WILLIAMS', 30); 

The view could have been constructed specifying the WITH READ ONLY clause, which 
prevents any updates, inserts, or deletes from being done to the base table through the 
view. If no WITH clause is specified, the view, with some restrictions, is inherently 
up da table. 

See Also: Oracle Database SQL Language Reference for syntax and 
semantics of the CREATE VIEW statement 

Join Views 

You can also create views that specifv more than one base table or view in the FROM 
clause. These are called join views. The following statement creates the 
divisionl_staff view that joins data from the emp and dept tables: 

CREATE Vim divisionl_staff AS 

SELECT ename, erapno, job, dname 

FROM emp, dept 

WHERE emp. deptno IN (10, 30) 
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AND erap.deptno = dept.deptno; 

Anupdatable join view is a join view where UPDATE, INSERT, and DELETE 
operations are allowed. See "Updating a Join View" on page 22-5 for further 
discussion. 

Expansion of Defining Queries at View Creation Time 

When a view is created, Oracle Database expands anv wildcard {*) in a top-level view 
quer)' into a column list The resulting querv is stored in the data dictionarv; anv 
subqueries are left intact. The column names in an expanded column list are enclosed 
in quote marks to account for the possibilit\' that the columns of the base object were 
originally entered with quotes and require theni for the querv to be syntactically 
correct. 

As an example, assume that the dep t view is created as follows: 

CREATE VIEW dept AS SELECT ' FROM scott.dept; 

The database stores the defining query of the dept view as; 

SELECT "DEPTNO", "DHAME", "LOC" FROM scott .dept; 

View^s created with errors do not have wildcards expanded. How^ever, if the view is 
eventuallv compiled without errors, wildcards in the defining query are expanded. 

Creating Views witli Errors 

If there are no svntax errors in a CREATE VIEW statement, the database can create the 
view even if the defining querv of the view cannot be executed. In this case, the view is 
considered "created with errors." For example, when a view is created that refers to a 
nonexistent table or an invalid column of an existing table, or when the view owner 
does not have the required privileges, the view can be created anvwav and entered 
into the data dictionary. However, the view is not yet usable. 

To create a view with errors, you must include the FORCE clause of the CREATE VIEW 
statement, 

CREATE FORCE VIEW AS . . , ; 

By default, views with errors are created as INVALID, When vou try to create such a 
view, the database returns a message indicating the view was created with errors. If 
conditions later change so that the quen' of an invalid view can be executed, the view 
can be recompiled and be made valid (usable). For information changing conditions 
and their impact on views, see "Managing Object Dependencies" on page 16-17, 



Replacing Views 



To replace a view, vou must have all of the privileges required to drop and create a 
view. If the definition of a view must change, the view must be replaced; you cannot 
use an ALTER VIEW statement to change the definition of a view. You can replace 
view^s in the following wavs: 

■ You can drop and re-create the view. 

Caution: When a view is dropped, all grants of corresponding 
object privileges are revoked from roles and users. After the view is 
re-created, privileges must be regranted. 
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■ You can redefine the view with a CREATE VIEW statement that contains the OR 
REPLACE clause. The OR REPLACE clause replaces the current definition of a view 
and preserves the current security authorizations. For example, assume that you 
created the Eales_Etaff view as shown earlier, and, in addition, vou granted 
se\'eral object privileges to roles and other users. However, now vou need to 
redefine the EaleE_Etaff view to change the department number specified in 
the WHERE clause. You can replace the current version of tlie sales_staf f view 
with the following statement: 

CREATE OR REPLACE Vim sales_staff AS 
SELECT empno, ename, deptno 
FROM emp 

WHERE deptno =30 
MITH CHECK OPTIOH CONSTRAIHT sales_staf f_cnst; 

Before replacing a view, consider the following effects: 

■ Replacing a view replaces the view definition in the data dictionary. All 
underlying objects referenced by the view are not affected, 

■ If a constraint in the CHECK OPTION was previously defined but not included in 
the new view definition, the constraint is dropped, 

■ All views dependent on a replaced view become invalid (not usable). In addition, 
dependent PL/SQL program units may become invalid, depending on what was 
changed in the new version of the view. For example, if onlv the WHERE clause of 
the view changes, dependent PL/SQL program units remain valid. However, if 
anv changes are made to the number of view columns or to the view column 
names or data t\'pes, dependent PL/SQL program units are invalidated. See 
"Managing Object Dependencies" on page 16-17 for more information on how the 
database manages such dependencies. 
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To issue a query or an INSERT . UPDATE, or DELETE statement against a view, you 
must have the SELECT. INSERT, UPDATE, or DELETE object privilege for the view, 
respectively, either explicitly or through a role, 

View^s can be queried in the same manner as tables. For example, to quen' the 
Divisionl_staf f view, enter a valid SELECT statement that references the view: 

SELECT ' FROM DivisionLstaf f ; 

ENAME EMPHO JOB DHAME 



CLARK 


7782 


MMAGER 


ACCODMTING 


KING 


7839 


PRESIDENT 


ACCOUMTING 


MITiTiFR 


7934 


CLERK 


ACCOUMTING 


ALLEN 


7499 


SATiF'^MM 


SATFS 


WARD 


7521 


SALESMAN 


SATF'^ 


JAMES 


7900 


CLERK 


SALES 


TURMER 


7844 


SALF'^MAU 


SATFS 


MARTIN 


7654 


SATFSMAN 


SALES 


BLAKE 


7698 


MAMAGER 


SALES 



With some restrictions, rows can be inserted into, updated in, or deleted from a base 
table using a view. The following statement inserts a new row into the emp table using 
the sales_staf f view: 

INSERT INTO sales_staff 

VALUES (7954, 'OSTER', 30); 
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Restrictions on DML operations for views use the following criteria in the order hsted: 

1. If a view is defined by a query that contains SET or DISTINCT operators, a GROUP 
BY clause, or a group function, then rows cannot be inserted into, updated in, or 
deleted from the base tables using the view. 

2. If a view is defined with WITH CHECK OPTION, a row cannot be inserted into, or 
updated in, the base table (using the view), if the view cannot select the row from, 
the base table. 

3. If a NOT NULL column that does not have a DEFAULT clause is omitted from the 
view, then a row cannot be inserted into the base table using the view. 

4. If the view was created by using an expression, such as DECODE (deptno, 10 , 

" SALES" . . . . ) . then rows cannot be inserted into or updated in the base table 
using the view. 

The constraint created by WITH CHECK OPTION of the sales_staff view only allows 
rows that have a department number of 30 to be inserted into, or updated in, the emp 
table. Alternatively, assume that the sales_Etaff view is defined by the following 
statement (that is, excluding the deptno column): 

CREATE Vim sales_staff AS 
SELECT empno, enarae 
FROM erap 

WHERE deptno = 10 
WITH CHECK OPTIOM CONSTRAINT sales_staEf_cnstr 

Considering this view definition, you can update the empno or ename fields of 
existing records, but you cannot insert rows into the emp table through the 
sales_staff view because the view does not let you alter the deptno field. If vou 
had defined a DEFAULT value of 10 on the deptno field, then you could perform 
inserts. 

When a user attempts to reference an invalid view, the database returns an error 
message to the user: 

ORA-04063: view ' view_name ' has errors 

This error message is returned when a view exists but is unusable due to errors in its 
query (whether it had errors when originally created or it was created successfully but 
became unusable later because underlying objects were altered or dropped). 
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An updatable join view (also referred to as a modifiable join view) is a view that 
contains more than one table in the top-level FROM clause of the SELECT statement, 
and is not restricted by the WITH READ ONLY clause. 

The rules for updatable join views are shown in the following table. Views that meet 
these criteria are said to be inherently updatable. 

Rule Description 



General Rule Any INSERT, UPDATE, or DELETE operation on a join view can 

modifj' only one underlying base table at a time. 
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Rule 



Description 



UPDATE Rule All updatiible columns of a join view must map to columns of a 

key- pre served table. See "Kev- Preserved Tables" on page 22-7 for a 
discussion of kev-preserved tables. If the view is defined with the 
WITH CHECK OPTION clause, then all join cokimns and all 
columns of repeated tables are not updatable. 

DELETE Rule Rows from a join view can be deleted as long as there is exactly one 

key-preserved table in the join. The key preserved table can be 
repeated in the ETiOM clause. If the view is defined with the WITH 
CHECK OPTION clause and the key preserved table is repeated, 
then the rows cannot be deleted from the view. 

INSERT Rule An INSERT statement must not explicitly or implicitly refer to the 

columns of a n on- key- pre served table. If the join view is defined 

with the MITH CHECK OPTIOH clause, INSERT statements are not 
permitted. 

There are data dictionary views that indicate v^fhether the columns in a join view are 
inherently updatable. See "Using the UPDATABLE_ COLUMNS Views" on page 22-11 
for descriptions of these views. 

Note: There are some additional restrictions and conditions that 
can affect whether a join view is inherently updatable. Specifics are 
listed in the description of the CREATE VIEW statement in the 
Oyacte Database SQL Lairgungc Reference. 

If a view is not inherently updatable, it can be made updatable by 
creating an INSTEAD OF trigger on it. See Oracle Database PL/SQL 
Language Reference for information about triggers, 

Additionallv, if a view is a join on other nested views, then the 
other nested views must be mergeable into the top level view. For a 
discussion of mergeable and unmergeable views, and more 
generallv, how the optimizer optimizes statements that reference 
views, see the Oracle Database Perfbrmance Timing Guide. 



Examples illustrating the rules for inherently updatable join views, and a discussion of 
key-preser\'ed tables, are presented in following sections. The examples in these 
sections work onlv if you explicitiv define the primarv and foreign keys in the tables, 
or define unique indexes. The following statements create the appropriately 
constrained table definitions for emp and dept. 



CREATE TABLE 


dept 


( 


deptno 




MUMBER(4) PEIMASY KEY, 


dname 




VARCHAR2 ( 14 ) , 


loc 




VARCHAR2 ( 13 ) ) ; 


CREATE TABLE 


emp ( 




en^ino 




MUMBER(4) PRIMARY KEY, 


ename 




VAHCHAR2{10) , 


job 




VARCHAR2 { 9 ) , 


ragr 




NUMBER (4) , 


sal 




HDMBER(7,2), 


ccanm 




NUMBER (7, 2), 


deptno 




NUMBER ( 2 ) , 



FOREIGN KEY (DEPTNO) REFERENCES DEPT(DEPTNO) 
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You could also omit the primary and foreign kev constraints listed in the preceding 
example, and create a UNIQUE INDEX on dept (deptno) to make the following 
examples work. 

The following statement created the emp_dept join view which is referenced in the 
examples: 

CREATE VIEU emp_dept AS 

SELECT emp.empno, erap.ename, erap. deptno, erap.sal, dept.dnaine, dept . loc 

FROM emp, dept 

WHERE emp. deptno = dept. deptno 

AND dept. loc IM ('DALLAS', 'NEW YOHK' , ' BOSTON '), ■ 

Key- Pre served Tables 

The concept of a key-preserved table is fundamental to understanding the restrictions 
on modifying join views, A table is key-preserved if every key of the table can also be 
a key of the result of the join. So, a kev-presen'ed table has its keys preserved through 
a join. 



Note: It is not necessary that the key or kevs of a table be selected 
for it to be key preserved. It is sufficient that if the key or kevs were 
selected, then they would also be keys of the result of the join. 

The key-preserving property of a table does not depend on the actual data in the table. 
It is, rather, a propert}' of its schema. For example, if in the emp table there was at most 
one employee in each department, then deptno would be unique in the result of a join 
of emp and dept, but dept would still not be a kev-preserved table. 

If you select all rows from emp_dept, the results are; 

EMPNO ENAME DEPTNO DHAME LOC 



10 


ACCOUMTIHG 


NEM YORK 


10 


ACCOUNTING 


NEW YORK 


10 


ACCOUNTING 


HEW YORK 


20 


RESEARCH 


DALLAS 


20 


RESEARCH 


DALLAS 


20 


RESEARCH 


DALLAS 


20 


RESEARCH 


DALLAS 


20 


RESEARCH 


DALLAS 



7782 CLARK 

7839 KING 

7934 MILLER 

7369 SMITH 

7875 ADAMS 

7902 FORD 

7788 SCOTT 

7565 JONES 

8 rows selected. 

In this view, emp is a key-preser\'ed table, because empno is a key of the emp table, 
and also a key of the result of thejoin, dept is nol a key-preserved table, because 
although deptno is a key of the dept table, it is not a key of the join, 

DML Statements and Join Views 

The general rule is that any UPDATE, DELETE, or INSERT statement on a join view can 
modify onlv one underlying base table. The following examples illustrate rules specific 

to UPDATE, DELETE, and INSERT statements, 

UPDATE Statements The following example shows an UPDATE statement that 
successfuUy modifies the emp_dept view; 

UPDATE eir[p_dept 

SET sal = sal ' 1.10 
WHERE deptno = 10; 
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The following UPDATE statement would be disallowed on the emp_d.ept view: 

UPDATE emp_dept 

SET loc = 'BOSTON' 
MHERE ename = ' SMITH ' ; 

This statement fails with an error (ORA-01779 cannot modify a column which 
maps to a non key-preserved table), because it attempts to modifv the base 
dept table, and the dept table is not key -pre served in the emp_dept view. 

In general, all updatable columns of a join view must map to columns of a 
key-preserved table. If the view is defined using the WITH CHECK OPTION clause, 
then all join columns and all columns taken from tables that are referenced more than 
once in the view are not modifiable. 

So, for example, if the emp_dept view were defined using WITH CHECK OPTION, the 
following UPDATE statement would fail: 

UPDATE eiitp_dept 

SET deptno = 10 

MHERE ename = ' SMITH ' ; 

The statement fails because it is trving to update a join column. 

See Also: Oracle Database SQL Language Reference for syntax and 
additional information about the UPDATE statement 

DELETE Statements You can delete from a join view provided there is one and only one 
key -preserved table in the join. The key-preserved table can be repeated in the FROM 
clause. 

The following DELETE statement works on the emp_dept view: 

DEIEPE FROM emp_dept 

WHERE ename = ' SMITH ' ; 

This DELETE statement on the emp_dept view is legal because it can be translated to a 
DELETE operation on the base emp table, and because the emp table is the only 
key -preserved table in the join. 

In the following view, a DELETE operation is permitted, because although there are 
two key-preserved tables, they are the same table. That is, the key-preserved table is 
repeated. In this case, the delete statement operates on the first table in the FROM list 
(el, in this example): 

CREATE VIEW emp_emp AS 

SELECT el. ename. e2,eii5>no, e2.deptno 

FROM emp el, emp e2 

IHEIRE el,empno = e2,empno; 

If a view is defined using the WITH CHECK OPTION clause and the key-preserved 
table is repeated, rows cannot be deleted from such a view, 

CREATE VIEW emp_mgr AS 

SELECT el. ename. e2, ename mname 
FROM emp el, emp e2 
WHERE el,mgr = e2.empno 
WITH CHECK OPTIOH; 

See Also: Oracle Database SQL Language Reference for syntax and 
additional information about the DELETE statement 
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INSERT Statements The following INSERT statement on the emp_dept view succeeds: 

INSERT IHTO emp_dept (ename, empno, deptno) 
VALUES ('KURODA', 9010, 40); 

This statement works because only one key -preserved base table is being modified 
(emp), and 40 is a valid deptno in the dept table (thus satisfying the FOREIGN KEY 
integrity constraint on the emp table). 

An INSERT statement, such as the foUowing, would fail for the same reason that such 
an UPDATE on the base emp table would fail: the FOREIGN KEY integrity constraint on 
the emp table is violated (because there is no deptno 77). 

INSERT IHTO emp_dept (ename, empno, deptno) 
VALUES ['KURODA', 9010, 77); 

The following INSERT statement would fail with an error (ORA- 017 7 6 cannot 
modify more than one base table through a join view): 

INSERT IHTO emp_dept (empno, ename, loc} 
VALUES [9010, 'KURODA', 'BOSTON'); 

An INSERT cannot implicitly or explicitiv refer to columns of a n on- key-preserved 
table. If the join view is defined using the InllTH CHECK OPTION clause, then you 
cannot perform an INSERT to it. 

See Also: Oracle Database SQL Language Reference for syntax and 
additional information about the INSERT statement 

Updating Views Tliat Involve Outer Joins 

Views that involve outer joins are modifiable in some cases. For example: 

CREATE VIEW emp_dept_o j 1 AS 

SELECT empno, ename, e. deptno, dname, loc 

PROM emp e, dept d 

WHERE e. deptno = d. deptno (+) ; 

The statement: 

SELECT ' FROM einp_dept_o] 1 ; 

Results in: 

EMPNO ENAME DEPTNO DNAME LOC 



7359 


SMITH 


40 


OPERATIONS 


BOSTON 


7499 


ALLEN 


30 


SALES 


CHICAGO 


7556 


JONES 


20 


RESEARCH 


DALLAS 


7654 


MARTIN 


30 


SALES 


CHICAGO 


7698 


BLAKE 


30 


SALES 


CHICAGO 


7782 


CLARK 


10 


ACCOUNTIHG 


NSa YORK 


7788 


SCOTT 


20 


RESEARCH 


DALLAS 


7839 


KIHG 


10 


ACCOUNTIHG 


HE','i YORK 


7844 


TUEHER 


30 


SALES 


CHICAGO 


7876 


ADAMS 


20 


RESEARCH 


DALLAS 


7900 


JAMES 


30 


SALES 


CHICAGO 


7902 


FORD 


20 


RESEARCH 


DALLAS 


7934 


MILLER 


10 


ACCOUNTIHG 


NSa YORK 


7521 


WARD 


30 


SALES 


CHICAGO 


14 rows 


selected. 
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Columns in the base emp table of emp_d.ept_o j 1 are modifiable through the view, 
because emp is a key-preserved table in the join. 

The following view also contains an outer join: 

CREATE VIEW emp_dept_oj 2 AS 

SELECT e.empno, e.enarne, e.deptno, d.dnarne, d.loc 

EROM emp e, dept d 

MHERE e.deptno (+} = d.deptno; 

The foUov/ing statement: 

SELECT ' FROM enip_dept_oj2 ; 

Results in: 

EMPHO ENAME DEPTHO DNAME LOC 



7782 


CLARK 


10 


ACCOUNTIHG 


NErt YORK 


7839 


KING 


10 


ACCOUNTIHG 


NEW YORK 


7934 


MILLER 


10 


ACCOUNTIHG 


NErt YORK 


7359 


SMITH 


20 


RESEARCH 


DALLAS 


7876 


ADAMS 


20 


RESEARCH 


DALLAS 


7902 


FORD 


20 


RESEARCH 


DALLAS 


7788 


SCOTT 


20 


RESEARCH 


DALLAS 


7556 


JOMES 


20 


RESEARCH 


DALLAS 


7499 


ALLEN 


30 


SAI.FS 


CHICAGO 


7698 


BLAKE 


30 


SAI.FS 


CHICAGO 


7654 


MARTIN 


30 


SALFS 


CHICAGO 


7900 


JAMFS 


30 


SAI.FS 


CHICAGO 


7844 


TURMER 


30 


SAI.FS 


CHICAGO 


7521 


WARD 


30 


SAI.FS 
OPERATIONS 


CHICAGO 
BOSTON 



15 rows selected. 

In this view, emp is no longer a key-preserved table, because the empno column in the 
result of the join can have nulls (the last row in the preceding SELECT statement). So, 
UPDATE, DELETE, and INSERT operations cannot be performed on this view. 

In the case of views containing an outer join on other nested views, a table is key 
preserved if the view or views containing the table are merged into their outer views, 
all the way to the top, A view which is being outer-joined is currentlv merged onlv if it 
is "simple," For example: 

SELECT coll, col2, ,,. FROM T; 

The select list of the view has no expressions, and there is no WHERE clause. 
Consider the following set of views: 

CREATE VIEif emp_v AS 

SELECT empno, ename, deptno 
FROM emp; 
CREATE VIEif emp_dept_ojl AS 
SELECT e,*, Loc, d.dnaine 
FROM emp_v e, dept d 

WHERE e, deptno = d.deptno {+) ; 

In these examples, emp_v is merged into emp_dept_o j 1 because emp_v is a simple 
view, and so emp is a key-preserved table. But if emp_v is changed as follows: 

CREATE VIBf emp_v_2 AS 

SELECT empno, ename, deptno 
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FROM emp 

WHERE sal > 1000; 

Then, because of the presence of the WHERE clause, enip_v_2 cannot be merged into 
emp_dept_o jl, and hence emp is no longer a key-preserved table. 

If vou are in doubt whether a view is modifiable, then you can select from the 
USER_UPDATABLE_COLUMNS view to see if it is. For example: 

SELECT owner, table_name, coluiim_name, updatable FROM USER_IIPDATABLE_COLT)MNS 
MHERE TABLEJfflE = ■EHP_DEPT_VIEW' ; 

This returns output similar to the following: 

OWMER TABI£ HME COLUMN HAM UPD 



SCOTT 


EMP DEPT V 


EMPHO 


HO 


SCOTT 


EMP DEPT V 


EHME 


HO 


SCOTT 


EMP_DEPT_V 


DEPTHO 


HO 


SCOTT 


EMP DEPT V 


DHfflE 


HO 


SCOTT 


EMP DEPT V 


LOC 


HO 


5 rows 


selected. 







Using the UPDATABLE. COLUMNS Views 

The views described in the following table can assist you to identify inherently 
updatable join views. 

View Description 

DBA_UPDATABLE_COLU Shows all columns in all tables and views that are modifiable, 
MNS 

ALL_UPDATABLE_COHJ Shows all columns in all tables and views accessible to the user that 
MNS are modifiable. 



USER_UPDATABLE_COL Shows all columns in all tables and views in the user's schema that 
DMNS are modifiable. 



The updatable columns in view emp_dept are shown below, 

SELECT COLUMN_HfflE, UPDATABLE 

FROM OSER_UPDATABLE_C0LUHNS 
WHERE TABLE_NAME = 'EMP_DEPT' ; 

COLUMH NAME UPD 



MPNO YES 

ENAME YES 

DEPTNO YES 

SAL YES 

DNAHE NO 

LOC NO 



6 rows selected. 



See Also: Oracle Database Reference for complete descriptions of 
the updatable column views 
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Altering Views 

You use the ALTER VIEW statement onlv to explicitly recompile a view that is invalid. 
If voLL want to change the definition of a view, see "Replacing Views" on page 22-3, 

The ALTER VIEW statement lets yon locate recompilation errors before run time. To 
ensure that the alteration does not affect the view or other objects that depend on it, 
you can explicitly recompile a view after altering one of its base tables. 

To use the ALTER VIEW statement, the view must be in your schema, or you must 

have the ALTER ANY TABLE system privilege. 

See Also: Oivcic Dnhtbasc SQL Language Reference for s\-ntax and 
additional information about the ALTER VIEW statement 



Dropping Views 



You can drop anv view contained in your schema. To drop a view in another user's 
schema, you must have the DROP ANY VIEW system privilege. Drop a vievir using the 
DROP VIEW statement. For example, the following statement drops the emp_dept 
view: 

DROP VIEW smp_deptr 

See Also: Oraeie Database SQL Language Reference for syntax and 
additional information about the DROP VIEW statement 



Managing Sequences 



This section describes aspects of managing sequences, and contains the following 
topics: 

About Sequences 

Creating Sequences 

Altering Sequences 

Using Sequences 

Dropping Sequences 



About Sequences 



Sequences are database objects from which muhiple users can generate unique 
integers. The sequence generator generates sequential numbers, which can help to 
generate unique primary kevs auton\atically, and to coordinate keys across multiple 
rows or tables. 

Without sequences, sequential values can onlv be produced programmaticallv, A new 
primar\" key value can be obtained by selecting the most recently produced value and 
incrementing it. This method requires a lock during the transaction and causes 
multiple users to wait for the next value of the primary kev; this waiting is known as 
serialization. If developers have such constructs in applications, then vou should 
encourage the developers to replace them with access to sequences. Sequences 
eliminate serialization and improve the concurrency of an application. 

See Also: Oracle Database Concepts for a more complete 
description of sequences 



22-12 Oracle Database Administrator's Guide 



Managing Sequences 



Creating Sequences 



To create a sequence in your schema, you must have the CREATE SEQUENCE svstem 
privilege. To create a sequence in another user's schema, you must have the CREATE 

ANY SEQUENCE privilege. 

Create a sequence using the CREATE SEQUENCE statement. For example, the 
following statement creates a sequence used to generate employee numbers for the 
empno column of the emp table: 

CREATE SEQUENCE emp_sequence 
IHCREMENT BY 1 
START WITH 1 
HOMAXVALUE 

CACHE 10; 

Notice that several parameters can be specified to control the function of sequences. 
You can use these parameters to indicate whether the sequence is ascending or 
descending, the starting point of the sequence, the minimum and maximum values, 
and the interval between sequence values. The NOCYCLE option indicates that the 
sequence cannot generate more values after reaching its maximum or minimum value. 

The CACHE clause preallocates a set of sequence numbers and keeps them in memory 
so that sequence numbers can be accessed faster When the last of the sequence 
numbers in the cache has been used, the database reads another set of numbers into 
the cache. 

The database might skip sequence numbers if you choose to cache a set of sequence 
numbers. For example, when an instance abnormally shuts down (for example, when 
an instance failure occurs or a SHUTDOWN ABORT statement is issued), sequence 
numbers that have been cached but not used are lost. Also, sequence numbers that 
have been used but not saved are lost as well. The database might also skip cached 
sequence numbers after an export and import. See Oracle Database Utilities for details. 

See Also: 

■ Oracle Database SQL Language Reference for the CREATE 
SEQUENCE statement syntax 

■ Oracle Real Application Clusters Deployment and Performance 
Guide for information about how caching sequence numbers 
improves performance in an Oracle Real Application Clusters 
environment 



Altering Sequences 



To alter a sequence, your schema must contain the sequence, or you must ha\'e the 
ALTER ANY SEQUENCE svstem privilege. You can alter a sequence to change any of 
the parameters that define how it generates sequence numbers except the sequence 
starting number. To change the starting point of a sequence, drop the sequence and 
then re-create it. 

Alter a sequence using the ALTER SEQUENCE statement. For example, the following 
statement alters the emp_sequence; 

ALTER SEQUEHCE emp_sequence 
IHCREMENT BY 10 
MAXVALUE 10000 
CYCLE 
CACHE 20; 
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See Also: Oracle Database SQL Language Reference for syntax and 
additional information about the ALTER SEQUENCE statement 



Using Sequences 



To use a sequence, vour schema nr»ust contain the sequence or vou must have been 
granted the SELECT object privilege for another user's sequence. Once a sequence is 
defined, it can be accessed and incremented by multiple users (who have SELECT 
object privilege for the sequence containing the sequence) with no waiting. The 
database does not wait for a transaction that has incremented a sequence to complete 
before that sequence can be incremented again. 

The examples outlined in the following sections show how sequences can be used in 
master/detail table relationships. Assume an order entry system is partially comprised 
of two tables, order 3_ tab (master table) and line_i teni3_tab (detail table), that 
hold information about customer orders, A sequence named order_3eq is defined by 
the following statement: 

CREATE SEQUENCE Order_seq 
START WITH 1 
INCREMENT BY 1 
HOMSXVALTIE 
HOCYCLE 
CACHE 20; 

Referencing a Sequence 

A sequence is referenced in SQL statements with the NEXTVAL and CURRVAL 
pseudocolumns; each new sequence number is generated by a reference to the 
sequence pseudocolumn NEXTVAL, while the current sequence number can be 
repeatedly referenced using the pseudo-column CURRVAL, 

NEXTVAL and CURRVAL are not reserved words or kevwords and can be used as 
pseudocolumn names in SQL statements such as SELECT, INSERT, or UPDATE, 

Generating Sequence Numbers with NEXTVAL To generate and use a sequence number, 
reference st'g_wiij lie, NEXTVAL. For example, assume a customer places an order The 
sequence number can be referenced in a values list. For example: 

IH3EET IHTO Orders.tab (Orderno, Custno} 
VALUES (Order_seq. NEXTVAL, 1032); 

Or, the sequence number can be referenced in the SET clause of an UPDATE statement. 
For example: 

UPDATE Orders_tab 

SET Orderno = Order_seq.MEXTVAL 
WHERE Orderno = 10112; 

The sequence number can also be referenced outermost SELECT of a quer}' or 
subquerv. For example: 

SELECT Order_seq , NEXTVAL FROM dual; 

As defined, the first reference to order_seq . NEXTVAL returns the value 1, Each 
subsequent statement that references order_seq , NEXTVAL generates the next 
sequence number (2, 3, 4,, , ,), The pseudo-column NEXTVAL can be used to generate as 
manv new sequence numbers as necessary. However, only a single sequence number 
can be generated for each row. In other words, if NEXTVAL is referenced more than 
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once in a single statement, then the first reference generates the next number, and all 
subsequent references in the statement return the same number 

Once a sequence number is generated, the sequence number is available only to the 
session that generated the number Independent of transactions committing or rolling 
back, other users referencing order_seq.NEXTVAL obtain unique values. If two users 
are accessing the same sequence concurrently, then the sequence numbers each user 
receives might have gaps because sequence numbers are also being generated by the 
other user. 

Using Sequence Numbers with CURRVAL To use or refer to the current sequence value of 
your session, reference seq_naiiic.C'aRRVAIj. CURRVAL can only be used if 
sci7_j7aii(L'.WEXTVAL has been referenced in the current user session (in the current or a 
previous transaction), CURRVAL can be referenced as many times as necessarv, 
including multiple times within the same statement. The next sequence number is not 
generated until NEXTVAL is referenced. Continuing with the previous example, vou 
would finish placing the customer's order by inserting the line items for the order: 

INSERT IHTO Line_iteinE_tab {Orderno, Partno, Quantity) 
VALUES (Order_seq. CURRVAL, 20321, 3}; 

INSEKT INTO Lirie_itemE_tab {Orderno, Partno, Quantity) 
VALUES (Order_seq. CURRVAL, 29374, 1); 

Assuming the INSERT statement given in the previous section generated a new 
sequence number of 347, both rows inserted by the statements in this section insert 
rows with order numbers of 347, 

Uses and Restrictions of NEXTVAL and CURRVAL CURRVAL and NEXTVAL can be used in 
the following places: 

VALUES clause of INSERT statements 

The SELECT hstof a SELECT statement 

The SET clause of an UPDATE statement 

CURRVAL and NEXTVAL cannot be used in these places: 

A subquery 

A view query or materialized view query 

A SELECT statement with the DISTINCT operator 

A SELECT statement with a GROUP BY or ORDER BY clause 

A SELECT statement that is combined with another SELECT statement with the 
UNION, INTERSECT, or MINUS set operator 

The WHERE clause of a SELECT statement 

DEFAULT value of a column in a CREATE TABLE or ALTER TABLE statement 

The condition of a CHECK constraint 

Caching Sequence Numbers 

Sequence numbers can be kept in the sequence cache in the System Global Area (SGA), 
Sequence numbers can be accessed more quickly in the sequence cache than they can 
be read from disk. 

The sequence cache consists of entries. Each entry can hold manv sequence numbers 
for a single sequence. 
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Follow these guidelines for fast access to all sequence numbers: 

■ Be sure the sequence cache can hold all the sequences used concurrently by your 
applications. 

■ Increase the number of values for each sequence held in the sequence cache. 

The Number of Entries in the Sequence Cache When an application accesses a sequence in 
the sequence cache, the sequence numbers are read quickly. However, if an 
apphcation accesses a sequence that is not in the cache, then the sequence must be read 
from, disk to the cache before the sequence numbers are used. 

If vour applications use many sequences concurrently, then your sequence cache 
might not be large enough to hold all the sequences. In this case, access to sequence 
numbers might often require disk reads. For fast access to all sequences, be sure your 
cache has enough entries to hold all the sequences used concurrently by your 
applications. 

The Number of Values in Each Sequence Cache Entry When a sequence is read into the 
sequence cache, sequence values are generated and stored in a cache entrv. These 
values can then be accessed quickly. The number of sequence values stored in the 
cache is determined by the CACHE parameter in the CREATE SEQUENCE statement. The 
default value for this parameter is 20, 

This CREATE SEQUENCE statement creates the seq2 sequence so that 50 values of the 
sequence are stored in the SEQUENCE cache; 

CREATE SEQUENCE seq2 
CACHE 50; 

The first 50 values of seq2 can then be read from the cache. When the 51st value is 
accessed, the next 50 values will be read from disk. 

Choosing a high value for CACHE lets vou access more successive sequence numbers 
with fewer reads from disk to the sequence cache, Howe\'er, if there is an instance 
failure, then all sequence values in the cache are lost. Cached sequence numbers also 
could be skipped after an export and import if transactions continue to access the 
sequence numbers while the export is running. 

If you use the NOCACHE option in the CREATE SEQUENCE statement, then the values of 
the sequence are not stored in the sequence cache. In this case, every access to the 
sequence requires a disk read. Such disk reads slow access to the sequence. This 
CREATE SEQUENCE statement creates the SEQ3 sequence so that its values are never 
stored in the cache: 

CREATE SEQUENCE seq3 
HOCACHE r 



Dropping Sequences 



You can drop anv sequence in your schema. To drop a sequence in another schema, 
you must have the DROP ANY SEQUENCE svstem privilege. If a sequence is no longer 
required, vou can drop the sequence using the DROP SEQUENCE statement. For 
example, the following statement drops the ord.er_Eeq sequence: 

DROP SEQUEHCE order_seq; 

When a sequence is dropped, its definition is removed from the data dictionary. Any 
synonyms for the sequence remain, but return an error when referenced. 
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See Also: Oracle Database SQL Language Reference for syntax and 
additional information about the DROP SEQUENCE statement 



Managing Synonyms 



This section describes aspects of managing synonyms, and contains the following 
topics: 

■ About Synonyms 

■ Creating Synonyms 

■ Using Synonyms in DML Statements 

■ Dropping Synonyms 



About Synonyms 



A synonym is an alias for a schema object. Synonyms can provide a level of security by 
masking the name and owner of an object and bv providing location transparency for 
remote objects of a distributed database. Also, they are convenient to use and reduce 
the complexity of SQL statements for database users. 

Svnonvms allow underlying objects to be renamed or moved, where only the 
svnonvm needs to be redefined and applications based on the synonym continue to 
function without modification. 

You can create both public and private svnonvms. A public svnonvm is owned bv the 
special user group named PUBLIC and is accessible to every user in a database. A 
private synonym is contained in the schema of a specific user and available only to the 
user and to grantees for the underlying object. 

Synonyms themselves are not securable. When you grant object privileges on a 
svnonvm, vou are really granting pri\'ileges on the underlying object, and the 
synonym is acting only as an alias for the object in the GRANT statement. 

See Also: Oracle Database Concepts for a more complete 
description of synonyms 



Creating Synonyms 



To create a private synonym in your own schema, you must have the CREATE 
SYNONYM privilege. To create a private synonvm in another user's schema, vou must 
have the CREATE ANY SYNONYM privilege. To create a public synonym, vou must 

have the CREATE PUBLIC SYNONYM system privilege. 

Create a synonvm using the CREATE SYNONYM statement. The underlying schema 
object need not exist, nor do vou need privileges to access the object for the CREATE 
SYNONYM statement to succeed. The following statement creates a public synonym 
named public_emp on the emp table contained in the schema of jward: 

CREATE PUBLIC SYNOHYM public_eii5> FOR jward.emp 

When you create a synonym for a remote procedure or function, you must qualify the 
remote object with its schema name. Alternatively, I'ou can create a local public 
synonym on the database where the remote object resides, in which case the database 
hnk must be included in all subsequent calls to the procedure or function. 

See Also: Oracle Database SQL Language Reference for syntax and 
additional information about the CREATE SYNONYM statement 
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Using Synonyms in DML Statements 

YoLL can successfully use anv private synonvm contained in vour schema or anv public 
svnonym, assuming that vou have the necessarv privileges to access the underlying 
object, either explicitly, from an enabled role, or from PUBLIC. You can also reference 
any private synonym contained in another schema if you have been granted the 
necessary object privileges for the underlying object. 

You can reference another user's synonvm using only the object privileges that vou 
have been granted. For example, if you have only the SELECT privilege on the 
jward.emp table, and the synonym jward . employee is created for jward. emp, you 
can query the jward. employee svnonym, but vou cannot insert rows using the 

jward. employee synonym, 

A synonym can be referenced in a DML statement the same way that the underlying 
object of the synonym can be referenced. For example, if a svnom'm named employee 
refers to a table or view, then the following statement is valid: 

INSERT IHTO employee [empno, ename, job) 

VALUES (emp_sequence.NEXTVAL, 'SMITH', 'CLERK' ) ; 

If the synonvm named f ire_emp refers to a standalone procedure or package 
procedure, then you could execute it with the command 

EXECUTE Fire_erap{7344) r 

Dropping Synonyms 

You can drop anv private synonvm in vour own schema. To drop a private svnonym 
in another user's schema, vou must have the DROP ANY SYNONYM system privilege. 
To drop a public synonvm, you must have the DROP PUBLIC SYNONYM system 
privilege. 

Drop a svnonvm that is no longer required using DROP SYNONYM statement. To drop 
a private svnonym, omit the PUBLIC keyword. To drop a public synonym, include the 
PUBLIC keyword. 

For example, the following statement drops the private svnonvm named emp: 

DROP SYHONYM emp; 

The following statement drops the public svnonym named public_emp: 

DROP PUBLIC SYHOIJYM public_empr 

When vou drop a svnonvm, its definition is removed from the data dictionary. All 
objects that reference a dropped svnonym remain. However, they become invalid (not 
usable). For more information about how dropping synonyms can affect other schema 
objects, see "Managing Object Dependencies". 

See Also: Oracle Database SQL Language Reference for syntax and 
additional information about the DROP SYNOHYM statement 

Views, Synonyms, and Sequences Data Dictionary Views 

The following views display information about views, synonyms, and sequences: 
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View Description 


DBA_VIEWS DBA view describes all views in the database. ALL view is restricted to 
„- -. -,__-_ views accessible to the current user. USER view is restricted to views 

owned by the current user 
USER_VIEW3 


DBA_SYMOtJYMS 
ALL_SYMOHYMS 
USER_3YH0NYMS 


These views describe s)Tionyms. 


DBA_SEQUEHCES 
ALL_SEQUEHCES 
USER_SEQUENCES 


These views describe sequences. 


DBA_UPDATABLE_COLaMIlS 
ALL_UPDATABLE_COLUMflS 
USER_UPDATABLE_COLUMNS 


These views describe all columns in join views that are updatable. 



See Also: Oracle Database Rejerence for complete descriptions of 
these views 
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Repairing Corrupted Data 



In this chapter: 

■ Options for Rep.iiring Data Block Corruption 

. About the DBMS_REPAIR Package 

. Using the DBMS_REPAIR Package 

. DBMS_REPAIR Examples 



Note: If you are notfamiUar with the DBMS_REPAIR package, 
then it is recommended that vou work with an Oracle Support 
Services annlvst when performing any of the repair procedures 
included in this package. 

Options for Repairing Data Block Corruption 

Oracle Database provides different methods for detecting and correcting data block 
corruption. One method of correction is to drop and re-create an object after the 
corruption is detected. However, this is not always possible or desirable. If data block 
corruption is limited to a subset of rows, then another option is to rebuild the table by 
selecting all data except for the corrupt rows. 

Another wav to manage data block corruption is to use the DBMS_REPAIR package. 
You can use DBMS_REPAIR to detect and repair corrupt blocks in tables and indexes. 
You can continue to use objects w^hile you attempt to rebuild or repair them. 



Note: Any corruption that involves the loss of data requires 
analysis and understanding of how that data fits into the overall 
database system. Depending on the nature of the repair, you might 
lose data, and logical inconsistencies can be introduced. You must 
determine whether the repair approach provided by this package is 
the appropriate tool for each specific corruption problem. 



About the DBIVJS.REPAIR Package 



This section describes the procedures contained in the DBMS_REPAIR package and 
notes some limitations and restrictions on their use. 

See Also: Oracle Dahibnsc PL/SQL Packiiges and Tijpcs Reference for 
more information on the svntax, restrictions, and exceptions for the 

DBMS_EEPAIE procedures 
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DBMS_REPAIR Procedures 

The following table lists the procedures included in the DBMS_REPAIR package. 



Procedure Name 


Description 


ADMIH_TABLES 


Provides administrative functions (create, drop, purge) for 
repair or orphan key tables. 

Note; These tables are always created in the SYS schema. 


CHECK_OBJECT 


Detects and reports corruptions in a table or index 


DUMP_ORPHAM_KEYS 


Reports on index entries that point to rows in corrupt data 
blocks 


FIX_CORRUPT_BL0CKS 


Marks blocks as software corrupt that have been previously 
identified as corrupt by the CHECK_OBJECT procedure 


REBUILD FBRFTiISTS 


Rebuilds the free lists of the object 


SEGMENT_FIX_S TATUS 


Provides the capability to fix the corrupted state of a bitmap 
entry when segment space management is AUTO 


SKIP_CORRUPT_BL0CKS 


When used, ignores blocks marked corrupt during table and 
index scans. If not used, you get error 0RA-157B when 
encountering blocks marked corrupt. 



These procedures are further described, with examples of their use, in 
"DBMS_REPAIR Examples" on page 23-5. 

Limitations and Restrictions 

DBMS_REPAIE procedures have the following limitations; 

■ Tables with LOB datatvpes, nested tables, and varrays are supported, but the out 
of line columns are ignored, 

■ Clusters are supported in the SKIP_CORRUPT_BLOCKS and 
REBUILD_FREELISTS procedures, but not in the CHECK_OBJECT procedure. 

■ Index- organized tables and LOB indexes are not supported. 

■ The DUMP_ORPHAISI_KEYS procedure does not operate on bitmap indexes or 
function-based indexes, 

■ The DUMP_ORPHAISI_KEYS procedure processes keys that are no more than 3,950 
bytes long. 



Using the DBMS_REPAIR Package 



The following approach is recommended when considering DBMS_REPAIR for 
addressing data block corruption: 

■ Task 1: Detect and Report Corruptions 

. Task 2: Evaluate the Costs and Benefits of Using DBMS_REPA1R 

■ Task 3: Make Objects Usable 

■ Task 4: Repair Corruptions and Rebuild Lost Data 
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Task 1 : Detect and Report Corruptions 



The first task is the detection iind reporting of corruptions. Reporting not onlv 
indicates what is wrong with a block, but also identifies the associated repair directive. 
There are several ways to detect corruptions. Table 23—1 describes the different 
detection methodologies. 

Table 23-1 Comparison of Corruption Detection Methods 

Detection Method Description 

DBMS_REPAIR PL /SQL Performs block checking for a specified table, partition, or index. It 
package populates a repair table with results. 

DB_VEHIFY utility Performs block checking on an offline database 

ANALYZE TABLE SQL Used with the VALIDATE STRUCTURE option, the ANALYZE 
statement TABLE statement verifies the integrity of the structure of an index, 

table, or cluster; checks or verifies that tables and indexes are 

synchronized, 

DB_BLOCK_CHECKIHG When DB_BLOCK_CHECKING=TRUE, corrupt blocks are identified 
initialization parameter before they are marked corrupt. Checks are performed when 
changes are made to a block. 



DBMS_REPAIR: Using the CHECK_OBJECT and ADMIN_TABLES Procedures 

The CHECK_OBJEGT procedure checks and reports block corruptions for a specified 
object, Similarto the ANALYZE. . .VALIDATE STRUCTURE statement for indexes 
and tables, block checking is performed for index and data blocks. 

Not onlv does CHECK_OBJECT report corruptions, but it also identifies anv fixes that 
would occur if FIX_CORRUPT_BLOCKS is subsequently run on the object. This 
information is made available by populating a repair table, which must first be created 
by the ADMIW_TABLES procedure. 

After you run the CHECK_OBJECT procedure, a simple querv on the repair table 
shows the corruptions and repair directives for the object. With this information, vou 
can assess how best to address the reported problems, 

DB_VERIFY: Performing an Offline Database Check 

Use DB_VERIFY as an offline diagnostic utiliK" when you encounter data corruption. 
See Also: Oracle Database Utilities for more information about 

DB_VERIFY 

ANALYZE: Reporting Corruption 

The ANALYZE TABLE. . .VALIDATE STRUCTURE statement validates the structure of 
the analyzed object. If the database encounters corruption in the structure of the object, 
then an error message is returned. In this case, drop and re-create the object. 

You can use the CASCADE clause of the ANALYZE TABLE statement to check the 
structure of the table and all of its indexes in one operation. Because this operation can 
consume significant resources, there is a FAST option that performs a lightweight 
check. See "Validating Tables, Indexes, Clusters, and Materialized Views" on page 16-3 
for details. 

See Also: 

■ Oracle Database SQL Language Reference for more information 
about the ANALYZE statement 
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DB_BLOCK_CHECKING Initialization Parameter 

You can enable database block checking by setting tlie DB_BLOCK_CHECKIHG 
initialization parameter to TRUE. This checks data and index blocks for internal 
consistency whenever thev are modified. DB_BLOCK_CHECKING is a dynamic 
parameter, modifiable by the ALTER SYSTEM SET statement. Block checking is 
always enabled for the system tabiespace. 

See Also: Oracle Database Reference for more information about the 
DB_BLOCK_CHECKING initialization parameter 

Task 2: Evaluate the Costs and Benefits of Using DBMS_REPAIR 

Before using DBMS_REPAIR vou must weigh the benefits of its use in relation to the 
liabilities. You should also examine other options available for addressing corrupt 
objects. Begin by answering the following questions: 

■ What is the extent of the corruption? 

To determine if there are corruptions and repair actions, execute the 
CHECK_OBJECT procedure and query the repair table. 

■ What other options are available for addressing block corruptions? Consider the 
following: 

- If the data is available from another source, then drop, re-create, and 
repopulate the object. 

Issue the CREATE TABLE ... AS SELECT statement from the corrupt table to 
create a new one, 

- Ignore the corruption by excluding corrupt rows from SELECT statements, 

- Perform media recovery, 

■ What logical corruptions or side effects are introduced when vou use 
DBMS_REPAIR to make an object usable? Can these be addressed? What is the 
effort required to do so? 

It is possible that you do not have access to rows in blocks marked corrupt. 
However, a block can be marked corrupt even if there are rows that vou can 
validly access. 

It is also possible that referential integrity constraints are broken when blocks are 
marked corrupt If this occurs, then disable and reenable the constraint; any 
inconsistencies are reported. After fixing all problems, you should be able to 
reenable the constraint. 

Logical corruption can occur when there are triggers defined on the table. For 
example, if rows are reinserted, should insert triggers be fired or not? You can 
address these issues onlv if you understand triggers and their use in your 
installation. 

If indexes and tables are not synchronized, then execute the DUMP_ORPHAN_KEYS 
procedure to obtain information from the keys that might be useful in rebuilding 
corrupted data. Then issue the ALTER INDEX, , , REBUILD ONLINE statement to 
synchronize the table with its indexes, 

■ If repair involves loss of data, can this data be retrieved? 

You can retrieve data from the index when a data block is marked corrupt. The 
DUMP_ORPHAN_KEYS procedure can help you retrieve this information. 
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Task 3: Make Objects Usable 

DBMS_REPAIR makes the object usable by ignoring corruptions during table and 
index scans. 

Corruption Repair: Using the FiX_CORRUPT_BLOCKS and 
SKiP_CORRUPT_BLOCKS Procedures 

You can make a corrupt object usable by establishing an envirorunent that skips 
corruptions that remain outside the scope of DBMS_REPAIR capabilities. 

If corruptions involve a loss of data, such as a bad row in a data block, ail such blocks 
are marked corrupt by the FIX_CORRUPT_BLOCKS procedure. Then you can run the 
3KIP_C0RRUPT_BL0CKS procedure, which skips blocks that are marked as corrupt. 
When the SKIP_FLAG parameter in the procedure is set, table and index scans skip all 
blocks marked corrupt. This applies to both media and software corrupt blocks. 

Implications when Skipping Corrupt Blocks 

If an index and table are not synchronized, then a SET TRANSACTION READ ONLY 
transaction can be inconsistent in situations where one query probes onlv the index, 
and a subsequent querv probes both the index and the table. If the table block is 
marked corrupt, then the two queries return different results, thereby breaking the 
rules of a read-only transaction. One way to approach this is not to skip corruptions in 
a SET TRANSACTION READ ONLY transaction. 

A similar issue occurs when selecting rows that are chained, A query of the same row 
mav or may not access the corruption, producing different results. 

Task 4: Repair Corruptions and Rebuild Lost Data 

After making an object usable, perform the following repair activities. 

Recover Data Using the DUMP_ORPHAN_KEYS Procedures 

The DUMP_ORPHAN_KEYS procedure reports on index entries that point to rows in 
corrupt data blocks. All such index entries are inserted into an orphan key table that 
stores the key and rowid of the corruption. 

After the index entry information has been retrieved, you can rebuild the index using 
theALTER INDEX. . .REBUILD ONLINE statement. 

Fix Segment Bitmaps Using the SEGMENT_FIX_STATUS Procedure 

Use this procedure if free space in segments is being managed by using bitmaps 

(SEGMENT SPACE MANAGEMENT AUTO). 

This procedure recalculates the state of a bitmap entry based on the current contents of 
the corresponding block. Alternatively, vou can specifv that a bitmap entrv be set to a 
specific value. Usually the state is recalculated correctly and there is no need to force a 
setting. 

DBMS.REPAIR Examples 

This section includes the following topics: 

■ Examples: Building a Repair Table or Orphan Key Table 

■ Example: Detecting Corruption 

■ Example: Fixing Corrupt Blocks 
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■ Example: Finding Index Entries Pointing to Corrupt Data Blocks 

■ Example: Skipping Corrupt Blocks 

Examples: Building a Repair Table or Orphan Key Table 

The ADMIN_TABLE procedure is used to create, purge, or drop a repair table or an 
orphan key table. 

A repair table provides information about the corruptions that were found bv the 
CHECK_OBJECT procedure and how these will be addressed if the 
FIX_COHRUPT_BL0CKS procedure is run. Further, it is used to drive the execution of 
the FIX_CORRUPT_BLOCKS procedure. 

An orphan key table is used when the DUMP_ORPHaN_KEYS procedure is executed 
and it discovers index entries that point to corrupt rows. The DUMP_ORPHAN_KEYS 
procedure populates the orphan kev table by logging its activity' and providing the 
index information in a usable manner. 

Example: Creating a Repair Table 

The following example creates a repair table for the users tablespace. 

BEGIH 
DBMS_REPAIR.flDHIH_TftBLES ( 

TABLE_NAME => 'REPAIR_TABI£ ' , 

TABLE_TYPE => dbiiis_repair .repair_table, 

ACTIOH => dl)iiis_repair .creabe_actioii, 

TABLESPACE => ' USERS ' ) ; 
END; 
/ 

For each repair or orphan kev table, a view is also created that eliminates anv rows 
that pertain to objects that no longer exist. The name of the view corresponds to the 
name of the repair or orphan key table and is prefixed by DBA_ (for example, 

DBA_REPAIR_TABLE or DBA_ORPHAN_KEY_TABLE). 

The following quer\' describes the repair table that was created for the users 
tablespace. 

DESC REPAIR_TABLE 
Hanie Null? Type 



OBJECTJD 


NOT 


HULL 


HUHBER 


TABLES PACE_rD 


NOT 


NULL 


lUHBER 


EELATIVE_FILE_ID 


HOT 


NULL 


lUHRRR 


BLOCK_ID 


MOT 


NULL 


lUMBER 


CORRUPT_T¥PE 


HOT 


NULL 


NUMBER 


SCHEMAJAME 


HOT 


NULL 


VARCHAR2(30) 


OBJECT_HAME 


HOT 


NULL 


VARCHAR2(30) 


BASEOBJECTJAME 






VARCHAR2(30) 


PARTITIOM_HAME 






VARCHAR2(30) 


COREUPT_DESCRIPTI0H 






VARCHAE2(2000] 


EEPAIR_DESCRI PTION 






VARCHAR2(2O0) 


MARKED_CORRUPT 


NOT 


NULL 


VARCHAR2 ( 10 ) 


CHECK TTMF'^TAHP 


NOT 


NULL 


DATE 


FIX_TIMESTfflP 






DATE 


EEFOHMAT TTMRt;TAH> 






DATE 
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Example: Creating an Orphan Key Table 

This example illustrates the creation of an orphan key table for the users tablespace. 

EEGIH 
DBMS_HEPAIR.ADMIH_TftBLES [ 

TABLE_NME => ' ORPHM_KE¥_TABI£ ' , 

TABLE_T¥PE => dbr[is_repair .orphan_table, 

ACTIOS => dbr[is_repair .create_action, 

TABLESPACE => 'USERS'); 
END; 
/ 

The orphan key table is described in the following query: 

DESC ORPHAN_KEY_TABI,E 
Name Null? IVpe 



SCHEMA_HAME HOT NULL VAECHAE2(30) 

INDEX_NAME NOT NULL VARCHAR2(30) 
IPAHT_NAME VARCHAR2 (30) 

INDEX_ID NOT NULL NUMBER 

TABLE_NAME NOT NULL VARCHAR2(30) 
PART_HAME VARCHAR2 (30) 

TABLE_ID NOT NULL NUMBER 

KEYEOWID NOT NULL ROWID 

KEY NOT NULL ROIVID 

DUMP TIMESTAMP NOT NULL DATE 



Example: Detecting Corruption 



The CHECK_OBJECT procedure checks the specified object, and populates the repair 
table with information about corruptions and repair directives. You can optionally 
specify a range, partition name, or subpartition name when you want to check a 
portion of an object. 

Validation consists of checking all blocks in the object that have not previously been 
marked corrupt. For each block, the transaction and data layer portions are checked 
for self consistency. During CHECK_OBJECT, if a block is encountered that has a 
corrupt buffer cache header, then that block is skipped. 

The following is an example of executing the CHECK_OBJECT procedure for the 
scott . dept table. 

SET SERVEROOTPUT ON 
DECLARE nuni_corrupt INT; 
EEGIM 

n"uiiL_corr"upt := 0; 
DEMS_REPAIR.CHECK_OBJECT ( 

SCHEMA_HAME => 'SCOTT', 

OBJECT_HAME => 'DEPT', 

REPAIR_TABLE_NAME => 'EEPAIR_TABLE' , 

CORHUPT_COUMT => nuni_corrupt) ; 
DBMS_OnTPUT.PUT_LINE( 'number corrupt: ' || TO_CHAR (num_corrupt) ) ; 
END; 
/ 

SQL'Plus outputs the following line, indicating one corruption: 

number corrupt: 1 
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Quer}'ing the repair table produces information describing the corruption and 
suggesting a repair action, 

SELECT OBJBCT_MME, BLOCK_ID, CORRUPT.TYPE , MSEKED_COERUPT, 
C0RRUPT_DE3CRIPTI0H, REPAIR_DESCRIPTIOH 
FROM REPAIR_TABLE r 

OBJECTJME BLOCK_ID CORRUPT_T¥PE MSEKED_COR 

COHRUPT_DESCRIPTIOH 

EEPAIR_DE3CRIPTI0M 

DEPT 3 1 FALSE 

kdbchk: row locked by non-existent transaction 

table=0 slot=0 

lockid=32 ktbbhitc=l 
mark block software corrupt 

The corrupted block has not yet been marked corrupt, so this is the time to extract any 
meaningful data. After the block is marked corrupt, the entire block must be skipped. 



Example: Fixing Corrupt Biocks 



Use the FIX_CORRUPT_BLOCKS procedure to fix the corrupt blocks in specified 
objects based on information in the repair table that was generated by the 
CHECK_OBJECT procedure. Before changing a block, the block is checked to ensure 
that the block is still corrupt. Corrupt blocks are repaired by marking the block 
software corrupt. When a repair is performed, the associated row in the repair table is 
updated with a timestamp. 

This example fixes the corrupt block in table scott.dept that was reported by the 
CHECK_OBJECT procedure. 

SET SERVEROUTPUT ON 

DECLARE nuni_fix IMT; 

BEGIH 

n"uiiL_Eix := 0; 

DBMS_REPAIR.FIX_C0REUPT_BLOCKS ( 

SCHEMA_HAME => 'SCOTT', 

OBJECT_MAME=> ' DEPT ' , 

OBJECT_TYPE => dbms_repair . table_object, 

REPAIR_TABLE_HAME => 'EEPAIR_TABLE' , 

FIX_COUMT=> nuin_fix}; 
DBMS_OUTPUT.PUT_LINE( 'num fix: ' || TO_CHAE{nuin_fix) ) ; 
END; 
/ 

SQL'Plus outputs the following line: 

nuHL fix: 1 

The following query confirms that the repair was done. 

SELECT OBJECT_HAME, BLOCK_ID, MARKED_CORRUPT 
FROM REPAIR_TABLE r 

OBJECT_HAME BLOCK_ID MARKED_COR 

DEPT 3 TRUE 
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Example: Finding Index Entries Pointing to Corrupt Data Blocks 

The DUMP_ORPHAN_KEYS procedure reports on index entries that point to rows in 
corrupt data blocks. For each index entry, a row is inserted into the specified orphan 
key table. The orphan key table must have been previously created. 

This information can be useful for rebuilding lost rows in the table and for diagnostic 
purposes. 



Note: This should be run for every index associated with a table 
identified in the repair table. 

In this example, pk_dept is an index on the scott . dept table. It is scanned to 
determine if there are any index entries pointing to rows in the corrupt data block. 

SET SERVEROUTPUT OH 
DECLARE nuni_orphans INT; 
EEGIH 

nuiiL_orphanE : = ; 
DBMS_REPAIR.DUMP_ORPHAH_KEYS ( 

SCHEMA_HAME => 'SCOTT', 

OBJECT_HAME => 'PK.DEPT', 

OBJECT_TYPE => dbms_repair . index_object, 

REPAIR_TABI£_NAME => 'EEPAIR_TABI.E' , 

ORPHAF_TABI£_HAME=> 'OEPHAN_KEY_TABLE' . 

KEY_COHMT => nuiiL_orphans) ; 
DBMS_ODTPUT.PUT_LINE( 'orphan key count: ' || TO_CHAR(nuni_orphanE) ) ; 
END; 
/ 

The following output indicates that there are three orphan keys: 

orphan key count : 3 

Index entries in the orphan key table implies that the index should be rebuilt. This 
guarantees that a table probe and an index probe return the same result set 



Example: Skipping Corrupt Blocks 



The SKIP_CORRUPT_BLOCKS procedure enables or disables the skipping of corrupt 
blocks during index and table scans of the specified object. When the object is a table, 
skipping applies to the table and its indexes. When the object is a cluster, it applies to 
all of the tables in the cluster, and their respecti\'e indexes. 

The following example enables the skipping of software corrupt blocks for the 
scott . dept table: 

EEGIH 
DBMS_REPAIR.SKIP_C0ERUPT_BLOCKS ( 

SCHEMA_HAME => 'SCOTT', 

OBJECT_HAME => 'DEPT', 

OBJECT.IYPE => dbms_repair.table_object, 

FLAGS => dbin3_repair .skip_f lag) ; 
END; 
/ 

Quer}'ing scott's tables using the DBA_TABLES view shows that SKIP_CORRUPT is 
enabled for table scott . dept. 

SELECT OWNER, TABLE_NAME, SKIP_CORRUPT FROM DBA_TABLES 
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WHERE OlflJER = 


' SCOTT ■ ; 




OWNER 




TABI£_HME 


SCOTT 




ACCOUMT 


SCOTT 




BONUS 


SCOTT 




DEPT 


SCOTT 




DOCINDEX 


SCOTT 




EMP 


SCOTT 




RECEIPT 


SCOTT 




SALGRADE 


SCOTT 




SCOTT_EMP 


SCOTT 




SYS_I0T_0VER_12 2 55 


SCOTT 




WORK_AREA 



SKIP COR 



DISABLED 

DISABLED 

EHABLED 

DISABLED 

DISABLED 

DISABLED 

DISABLED 

DISABLED 

DISABLED 

DISABLED 



10 rows selected. 
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Database Resource Management and Task 

Scheduling 



Part VI discusses database resource management. It contains information about using 
the Oracle Database Resource Manager Other chapters discuss Scheduler, a product 
with functionalitv designed to simplifv vour management of tasks, but also to provide 
a rich set of scheduling functionality to suit many needs. 

This part contains the following chapters: 

Chapter 24, "Managing Automated Database Maintenance Tasks" 

Chapter 25, "Managing Resource Allocation with Oracle Database Resource 
Manager" 

Chapter 26, "Oracle Scheduler Concepts" 

Chapter 27, "Scheduhng Jobs with Oracle Scheduler" 

Chapter 28, "Administering Oracle Scheduler" 
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Managing Automated Database Maintenance 

Taslcs 



Oracle Database has automated a number of common maintenance tasks t}'pically 
performed bv database administrators. These automated maintenance tasks are 
performed wlien the system load is expected to be liglit. You can enable and disable 
individual maintenance tasks, and can configure when these tasks run and what 
resource allocations they are allotted. 

In this chapter: 

About Automated Maintenance Tasks 

About Maintenance Windows 

Configuring Automated Maintenance Tasks 

Configuring Maintenance Windows 

Configuring Resource Allocations for Automated Maintenance Tasks 

Automated Maintenance Tasks Reference 

Note: This chapter explains how to administer automated 
maintenance tasks using PL/SQL packages. An easier way is to use 
the graphical interface of Enterprise Manager. 

To manage automatic maintenance tasks with Enterprise Manager; 

1. Access the Database Home Page. 

See OracL' Dahibmi; 2 Dai/ DBA or the Oracle Enterprise Manager Grid 
Control online help for instructions. 

2. On the Database Home Page, click Serverto display the Server page. 

3. Under the Oracle Scheduler section, click Automated Maintenance Tasks 
to configure maintenance tasks, or Windows to configure maintenance 
windows. 

About Automated Maintenance Tasks 

Automated maintenance tasks are tasks that are started automaticallv at regular 
intervals to perform maintenance operations on the database. An example is a task 
that gathers statistics on schema objects for the query optimizer Automated 
maintenance tasks run in maintenance windows, which are predefined time inter\'als 
that are intended to occur during a period of low svstem load. You can customize 
maintenance windows based on the resource usage patterns of your database, or 
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disable certain default windows from running. You can also create your own 
maintenance windows. 

Oracle Database has three predefined automated maintenance tasks: 

■ Automatic Optimizer Statistics Collection — Collects optimizer statistics for all 
schema objects in the database for which there are no statistics or onlv stale 
statistics. The statistics gathered by this task are used bv the SQL query optimizer 
to improve the performance of SQL execution. 

See Also: Oracle Database Performanec Tuning Guide for more 
information on automatic statistics collection 

■ Automatic Segment Advisor — Identifies segments that have space available for 
reclamation, and makes recommendations on how to defragment those segments. 

You can also run the Segment Advisor manually to obtain more up-to-the-minute 
recommendations or to obtain recommendations on segments that the Automatic 
Segment Advisor did not examine for possible space reclamation. 

See Also: "Using the Segment Advisor" on page 17-16 for more 
inform.ation. 

■ Automatic SQL Tuning Advisor — Examines the performance of high-load SQL 
statements, and makes recommendations on how to tune those statements. You 
can configure this advisor to automatically implement SQL profile 
recommendations. 

See Also: Oracle Database Performance Tuning Guide for more 
information on SQL Tuning Advisor 

Bv default, all three automated maintenance tasks are configured to run in all 
maintenance windows. 



About Maintenance Windows 



A maintenance window is a contiguous time inter\'al during which automated 
maintenance tasks are run. Maintenance windows are Oracle Scheduler windows that 
belong to the window group named MAIWTEWAWCE_WIWDOW_GEOUP, A Scheduler 
window can be a simple repeating interval (such as "between midnight and 6 a,m,, 
everv Saturday"), or a more complex interval (such as "between midnight and 6 a,m,, 
on the last workday of everv month, excluding company holidavs"). 

When a maintenance window opens, Oracle Database creates an Oracle Scheduler job 
for each maintenance task that is scheduled to run in that window. Each job is 
assigned a job name that is generated at runtime. All automated maintenance task job 
names begin with ORASAT, For example, the job for the Automatic Segment Advisor 
might be called ORA5AT_SA_SPC_SY_2 6. When an automated maintenance task job 
finishes, it is deleted from the Oracle Scheduler job system. However, the job can still 
be found in the Scheduler job histor}'. 

Note: To view^ job history, you must log in as the SYS user. 



In the case of a verv long maintenance window, all automated maintenance tasks 
except Automatic SQL Tuning Advisor are restarted every four hours. This feature 
ensures that maintenance tasks are run regularlv, regardless of window size. 
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The framework of aiitoniiited maintenance tasks relies on maintenance windows being 
defined in the database. Table 24-1 on page 24-7 lists the maintenance windows that 
are automatically defined with each new Oracle Database installation. 



See Also: 

■ Chapter 27, "Scheduling Jobs with Oracle Scheduler" for more 
information on windows and window groups. 

Configuring Automated l\/laintenance Tasks 

To enable or disable specific maintenance tasks in anv subset of maintenance 
windows, you can use the DBMS_AUTO_TASK_ADMIN PL/SQL package. 

This section contains the following topics: 

■ Enabling and Disabling Maintenance Tasks for aU Maintenance Windows 

■ Enabling and Disabling Maintenance Tasks for Specific Maintenance Windows 

Enabling and Disabling lUlaintenance Taslts for all Maintenance Windows 

You can disable a particular automated maintenance tasks for all maintenance 
windows with a single operation. You do so bv calling the DISABLE procedure of the 
DBMS_AUTO_TASK_ADMIW PL/SQL package without supplying the window_name 
argument. For example, vou can completely disable the Automatic SQL Tuning 
Advisor task as follows: 

BEGIH 

dbms_auto_task_adiniii . disable ( 

client_name => ' sql tuning advisor', 

operation => HULL, 

window_name => HULL) ; 
END; 

To enable this maintenance task again, use the ENABLE procedure, as follows: 

BEGIH 

dbmE_auto_task_adinin . enable { 

client_naine => 'sql tuning advisor', 

operation => HULL, 

window_name => HULL) ; 
END; 

The task names to use for the client_name argument are listed in the 

DBA_AUTOTASK_CLIEWT database dictionary view. 

To enable or disable all automated maintenance tasks for all windows, call the ENABLE 
or DISABLE procedure with no arguments, 

EXECUTE DBMS_AUT0_TA3K_ADMIH. DISABLE; 

See Also: 

■ "Automated Maintenance Tasks Database Dictionary Views" on 
page 24-7 

■ Omck Database PL/SQL Packages and Types Refcrence for more 
information on the DBMS_AUTO_TASK_ADMIN PL/SQL package. 



Managing Automated Database Maintenance Tasl<s 24-3 



Configuring Maintenance Windows 



Enabling and Disabling lUlaintenance Tasks for Specific Maintenance Windows 

Bv default, all maintenance tasks run in alJ predefined maintenance windows. You can 
disable a maintenance task for a specific window. The following example disables the 
Automatic SQL Tuning Advisor from running in the window MONDAY_WINDOW: 

BEGIH 

dliinE_auto_task_adinin . disable ( 

client_naiiLe => ' sql tuning advisor'. 

operation => HULL, 

window_naine => ' MONDAY_WINDDW ' | ; 
END; 



Configuring Maintenance Windows 



You mav want to adjust the predefined maintenance windows to a time suitable to 
your database environment or create a new maintenance window. You can customize 
maintenance windows using the DBMS_SCHEDULER PL/SQL package. 

This section contains the following topics: 

■ Modifj'ing a Maintenance Window 

■ Creating a New Maintenance Window 

■ Removing a Maintenance Window 



n/lodifying a Maintenance Window 



The DBMS_SCHEDULER PL/SQL package includes a SET_ATTRIBUTE procedure for 
modifying the attributes of a window. For example, the following script changes the 
duration of the maintenance window SATURDAY_WIWI>OW to 4 hours: 

BEGIN 

dbms_3cheduler .disable ( 

name => ■SATUEDAYJINDOM ' ) ; 
dbms_scheduler .set_attribute( 

name => 'SATURDAYJINDOW , 

attribute => 'DURATIOH', 

value => numtodsinterval [4 , 'hour')); 

dbms_scheduler . enable [ 

name => ' SATURDAY.WINDOW' ) ; 
END; 

Note that you must use the DBMS_ SCHEDULER . DI SABLE subprogram to disable the 
window before making changes to it, and then re-enable the window with 
DBMS_SCHEDULER . ENABLE when you are finished. If you change a window when it 
is currently open, the change does not take effect until the next time the window 
opens. 

See Also: "Using Windows" on page 27-22 for more information 
about modifying windows. 



Creating a New l\1aintenance Window 



The DBMS_SGHEDULER PL /SQL package provides the ADD_WINDOW_GROUP_MEMBER 
subprogram, which adds a window to a window group. To create a maintenance 
window, you must create a Scheduler window and then add it to the window group 

MAINTENANCE WINDOW GROUP. 
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The following example uses the DBMS_SCHEDULER package to create a maintenance 
window called EARLY_MORWIWG_MIWDOW. This window runs for one hour daily 
between 5 a.m. and 6 a.m. 

BEGIH 

dl>ins_scheduler .creal:e_window( 

wiridow_naine => 'EARLY_M0RHIHG_WIND01 ' , 

duration => nurotodsinterval (1, 'hour'), 

resource_plan => ' DEFAULT_MftIHTENMCE_PLM ' , 

repeat_interval => ' FREQ=DAILY;BYHOUR=5;B¥MIHDTE=0;B¥SECOHD=0 ' ) ; 
dbms_scheduler .add_window_group_member { 

group_nanie => ' MfiIMTENAMCE_WINDOW_GROUP ' , 

window_list => ' EARLY_HOHHING_WIIJDOM ' ] ; 
END; 

See Also: 

■ "Creating Windows" on page 27-23 

■ Oracle Database PL/SQL Packages and Types Rejerence for 
information on the DBMS_SCHEDULER package 

Removing a Maintenance Window 

To remove an existing maintenance window, remove it from the 
MAIWTEWAWCE_WIWDOW_GROUP window group. The window continues to exist but 
no longer runs automated maintenance tasks. Anv other Scheduler jobs assigned to 
this window continue to run as usual. 

The following example removes EARLY_MORNING_WINDOW from the window group: 

BEGIH 
EaMS_SCHEDULER.EEMOUE_HINDOW_GR0UP_MEMBER( 

group_name => ' MAIHTENAHCE_WIND0W_GROUP ' , 

window_li3t => ' EARLY_MORBING_WINDOW ' ] ; 
END; 

See Also: 

■ "Dropping a Member from a Window Group" on page 27-32 

■ "Dropping Windows" on page 27-26 

■ Oracle Database PL/SQL Packages and Types Reference for 
information on the DBMS_SCHEDt)LER package 

Configuring Resource Allocations for Automated Maintenance Tasks 

This section contains the following topics on resource allocation for maintenance 
windows: 

■ About Resource Allocations for Automated Maintenance Tasks 

■ Changing Resource Allocations for Automated Maintenance Tasks 

See Also: Chapter 25, "Managing Resource Allocation with 
Oracle Database Resource Manager" 

About Resource Allocations for Automated Maintenance Tasks 

By default, all predefined maintenance windows use the resource plan 
DEFAULT_MAINTEWAWCE_PLAN. Automated maintenance tasks run under its subplan 
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OEASAUTOTASK_SUB_PLAW. This siibplan divides its portion of totiit resource 
allocation equally among the maintenance tasks, 

DEFAULT_MAINTEWAWCE_PLAW defines the following resource allocations: 



Consumer Group/subplan 


Level 1 


Level 2 


ORAS AUTOTASK_SUB_PLAN 


- 


25% 


0RASDIAGK03TIC3 


- 


5% 


OTHER_GROUPS 


- 


70% 


SYS_GROUP 


100% 


1 



In this plan, any sessions in the SYS_GROUP consum.er group get priority. {Sessions in 
this group are sessions created bv user accounts SYS and SYSTEM, } Anv resource 
allocation that is unused bv sessions in SYS_GROUP is then shared bv sessions 
belonging to the other consumer groups and subplans in the plan. Of that allocation, 
25"o goes to maintenance tasks, 5"u goes to background processes performing 
diagnostic operations, and 70% goes to user sessions. To reduce or increase resource 
allocation to the automated maintenance tasks, vou make adjustments to 
DEFAULT_MAIWTEWAWCE_PLAW. See "Changing Resource Allocations for Automated 
Maintenance Tasks" on page 24-6 for more information. 

Note that as with any resource plan, the portion of an allocation that is not used bv a 
consumer group or subplan is available for other consumer groups or subplans. Note 
also that the Database Resource Manager does not begin to limit resource allocations 
according to resource plans until 100% of CPU is being used. 

Note: Although DEFAULT_MAINTENANCE_PLAN is the default, you 
can assign any resource plan to any maintenance window. 

See Also: Chapter 25, "Managing Resource Allocation with 
Oracle Database Resource Manager" for more information on 
resource plans. 

Changing Resource Allocations for Automated Maintenance Tasks 

To change the resource allocation for automated maintenance tasks within a 
maintenance window, you must change the percentage of resources allocated to the 
subplan ORASAUTOTASK_SUB_PLAW in the resource plan for that window. (By 
default, the resource plan for each predefined maintenance window is 
DEFAULT_MAIWTEWAWCE_PLAW.) You must also adjust the resource allocation for one 
or more other subplans or consumer groups in the window's resource plan such that 
the resource allocation at the top level of the plan adds up to 100''u. For information on 
changing resource allocations, see Chapter 25, "Managing Resource Allocation with 
Oracle Database Resource Manager". 

Automated Maintenance Tasks Reference 

This section contains the following reference topics for automated maintenance tasks: 

■ Predefined Maintenance Windows 

■ Automated Maintenance Tasks Database Dictionary Views 
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Predefined Maintenance Windows 



Bv default there are seven predefined maintenance windows, each one representing a 
dav of the week. Tlie weekend maintenance windows, SATURDAY_WINDOW and 
S UNI) A Y_ WINDOW, are longer in duration than the weekday maintenance windows. 
The window group MAINTENANCE_WINDOW_GROUP consists of these seven windows. 
The list of predefined maintenance windows is given in Table 24^1. 

Table 24-1 Predefined Maintenance Windows 



Window Name 


Description 




M0NDAY_WIHDOW 


Starts at 10 p.m 


on Monday and ends at 2 a.m.. 


TUESDAY_WIHDOW 


Starts at 10 p.m 


on Tuesday and ends at 2 a.m. 


WEDNEgDAY_WIKDOW 


Starts at 10 p.m 


on Wednesday and ends at 2 a.m. 


THUIiSDAY_WINDOW 


Starts at 10 p.m 


on Thursday and ends at 2 a.m. 


FRrDAY_WItn)OW 


Starts at 10 p.m 


on Friday and ends at 2 a.m. 


SATnRDAY_WINnOW 


Starts at 5 a.m. on Saturday and is 20 hours long. 


1 SUNI3AY_WIND0W 


Starts at 5 a.m. on Sunday and is 20 hours long, | 



Automated Maintenance Tasks Database Dictionary Views 

Table 24r-2 displays information about database dictionary views for automated 
maintenance tasks: 

Table 24-2 Automated Maintenance Tasks Database Dictionary Views 



View Name 


Description 


DBA_AUTOTASK_CLIENT_JOB 


Contains information about currently running Scheduler jobs created 
for automated maintenance tasks. It provides information about some 
objects targeted by those jobs, as well as some additional statistics from 
previous instantiations of the same task. Some of this additional data is 
taken from generic Scheduler views. 


DBA_AUTOTASK_CLIEtJT 


Provides statistical data for each automated maintenance task over 
7-day and 30-day periods. 


DBA_AUTOTASK_J0B_HI3TORY 


Lists the history of automated maintenance task job runs. Jobs are 
added to this view after they finish executing. 


DBA_AUTOTASK_W IHDOW_CLIENTS 


Lists the windows that belong to MAINTEHANCE_WINDOW_GROUP, 
along with the Enabled or Disabled status for the window for each 
maintenance task. Primarily used by Enterprise Manager 


EBA_AUTOTASK_CLIEMT_in:ST0RY 


Provides per-window history of job execution counts for each 
automated maintenance task. This information is viewable in the lob 

History page of Enterprise Manager. 



See Also: "Resource Manager Data Dictionary Views" on page 25^5 
for column descriptions for views. 
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Managing Resource Allocation with Oracle 

Database Resource Manager 



In this chapter; 

About Oracle Database Resource Manager 

Creating a Simple Resource Plan 

Creating a Complex Resource Plan 

Assigning Sessions to Resource Consumer Groups 

Enabling Oracle Database Resource Manager and Switching Plans 

Putting It All Together: Oracle Database Resource Manager Examples 

Maintaining Consumer Groups, Plans, and Directives 

Viewing Database Resource Manager Configuration and Status 

Monitoring Oracle Database Resource Manager 

Interacting with Operating-System Resource Control 

Oracle Database Resource Manager Reference 

Note: This chapter discusses using PL/SQL package procedures 
to administer the Resource Manager An easier way to administer 
the Resource Manager is with the graphical user interface of 
Enterprise Manager 

To administer the Resource Manager in Enterprise Manager: 

1. Access the Database Home page. 
See Orack' Dahibmi; 2 Dai/ DBA for instructions. 

2. At the top of the page, click Server to display the Server page. 

3. In the Resource Manager section, click Getting Started. 



About Oracle Database Resource Manager 

Oracle Database Resource Manager (the Resource Manager) enables you to optimize 
resource allocation among the manv concurrent database sessions. The following 
sections provide an overview of the Resource Manager: 

■ What Problems Does the Resource Manager Address? 

■ How Does the Resource Manager Address These Problems? 
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■ Elements of the Resource Manager 

■ About Resource Allocation Methods 

■ About Resource Manager Administration Privileges 

What Problems Does the Resource Manager Address? 

When database resource allocation decisions are left to the operating system, vou mav 
encounter the following problems: 

■ Excessive overhead 

Excessive overhead results from, operating system, context switching between 
Oracle Database server processes when the number of server processes is high. 

■ Inefficient scheduling 

The operating system deschedules database servers w^hile they hold latches, which 
is inefficient. 

■ Inappropriate allocation of resources 

The operating svstem distributes resources equally among all active processes and 
is unable to prioritize one task over another 

■ Inabilitv to manage database-specific resources, such as parallel execution servers 
and active sessions 

How Does the Resource Manager Address These Problems? 

The Resource Manager helps to overcome these problems by allowing the database 
more control over how hardware resources are allocated. In an environment with 
multiple concurrent users sessions that run jobs with differing priorities, all sessions 
should not be treated equallv. The Resource Manager enables you to classifv sessions 
into groups based on session attributes, and to then allocate resources to those groups 
in a way that optimizes hardware utilization for vour application environment. 

With the Resource Manager, you can: 

■ Guarantee certain sessions a minimum amount of processing resources regardless 
of the load on the svstem and the number of users, 

■ Distribute available processing resources bv allocating percentages of CPU time to 
different users and applications. In a data warehouse, a higher percentage can be 
given to ROLAP (relational online analvtical processing) applications than to batch 
jobs. 

■ Limit the degree of parallelism of any operation performed bv members of a 
group of users, 

■ Create an active session pool. An active session pool consists of a specified 
maximum number of user sessions allowed to be concurrently active within a 
group of users. Additional sessions bevond the maximum are queued for 
execution, but vou can specifv a timeout period, after which queued jobs will 
terminate. The active session pool limits the total number of sessions activetv 
competing for resources, thereby enabling active sessions to make faster progress, 

■ Manage runawav sessions or calls bv detecting when thev consume more than a 
specified amount of CPU or I/O. Such sessions can be automatically terminated or 
switched into a different (lower priorit\') group. 
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■ Prevent the execution of operations that the optimizer estimates will run for a 
longer time than a specified limit. 

■ Limit the amount of time that a session can be idle. This can be further defined to 
mean only sessions that are blocking other sessions, 

■ Configure an instance to use a particular scheme for allocating resources. You can 
dynamically change the scheme, for example, from a daytime scheme to a 
nighttime scheme, without having to shut down and restart the instance. You can 
also schedule a scheme change with Oracle Scheduler. See Chapter 26, "Oracle 
Scheduler Concepts" for more information. 

Elements of the Resource Manager 

The elements of the Resource Manager are described in the following table. 

Element Description 

SesDurce consumer group A group of aesaions that are grouped together b^sed on 
resource requirements. The Resource Manager allocates 
resources to resource consumer groups, not to individual 
sessions. 

Resource plan A container for directives that specify how resources are 

allocated to resource consumer groups. You specify liow the 
database iillocates resources by activating a specific resource 
plan. 

Resource plan directive Associates a resource consumer group with a particular plan 

and specifies how resources are to be allocated to that 
resource consumer group. 

You use the DBMS_RESOURCE_MANAGER PL/SQL package to create and maintain 
these elements. The elements are stored in tables in the data dictionary. You can view 
information about them with data dictionary views. 

See Also: "Resource Manager Data Dictionary Views" on 
page 25-45 

About Resource Consumer Groups 

A resource consumer group (consumer group) is a collection of user sessions that are 
grouped together based on their processing needs. When a session is created, it is 
automatically mapped to a consumer group based on mapping rules that you set up. 
As a database administrator (DBA), vou can manuallv switch a session to a different 
consumer group. Similarly, an application can run a PL/SQL package procedure that 
switches its session to a particular consumer group. 

Because the Resource Manager allocates resources (such as CPU) only to consumer 
groups, when a session becomes a member of a consumer group, its resource 
allocation is then determined bv the allocation for the consumer group. By default, 
each session in a consumer group shares the resources allocated to that group with 
other sessions in the group in a round robin fashion. 

There are three special consumer groups that are alwavs present in the data 
dictionary. They cannot be modified or deleted. They are: 

■ SYS GROUP 
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This is the initial consumer group for all sessions created bv user accounts SYS or 
SYSTEM. This initial consumer group can be overridden by session-to-consumer 
group mapping rules, 

■ DEFAULT_COWSUMER_GROUP 

This is the initial consumer group for all sessions started bv user accounts other 
than SYS and SYSTEM, This initial consumer group can be overridden by 
session-to-consumer group mapping rules. DEFAULT_CONSUMEE_GEOUP cannot 
be named in a resource plan directive. 

■ OTHER_GROUPS 

This group applies collectively to all sessions that belong to a consumer group that 
is not part of the currently active plan, including sessions that belong to 
DEFAULT_COWSUMEE_GEOUP. OTHEE_GEOUPS must have a resource plan 
directive specified in every plan. It cannot be exphcitly assigned to sessions 
through mapping rules. 

See Also: 

■ Table 25-2, " Predefined Resource Consumer Groups" on 
page 25-43 

■ "Specifying Session-lo-Consumer Group Mapping Rules" on 
page 25-24 

About Resource Plan Directives 

The Resource Manager allocates resources to consumer groups according to the set of 
resource plan directives (directives) that belong to the currentlv active resource plan. 
There is a parent-child relationship betv^feen a resource plan and its resource plan 
directives. Each directive references one consumer group, and no two directives for 
the currentlv active plan can reference the same consumer group, 

A directive has a number of ways in which it can limit resource allocation for a 
consumer group. For example, it can control how much CPU the consumer group gets 
as a percentage of total CPU, and it can limit the total number of sessions that can be 
active in the consumer group. See "About Resource Allocation Methods" on page 25-6 
for more information. 

About Resource Pians 

In addition to the resource plans that are predefined for each Oracle database, you can 
create anv number of resource plans. However, onlv one resource plan is active at a 
time. When a resource plan is active, each of its child resource plan directives controls 
resource allocation for a different consumer group. Each plan must include a directive 
that allocates resources to the consumer group named OTHER_GROUPS. 
GTHEE_GEOUPS applies to all sessions that belong to a consumer group that is not part 
of the currentlv active plan. 
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Note: Although the term "resource plan" (or just "plan") denotes one 
element of the Resource Manager, in this chapter it is also used to 
refer to a complete ivsoura' plan schema, which includes the resource 
plan element itself, its resource plan directives, and the consumer 
groups that the directives reference. For example, when this chapter 
refers to the DAYTIME resource plan, it could mean either the resource 
plan element named DAYTIME, or the particular resource allocation 
schema that the DAYTIME resource plan and its directives define. 
Thus, for brevit}', it is acceptable to sav, "the DAYTIME plan favors 
interactive applications over batch apphcations." 



Example: A Simple Resource Plan 

Figure 25-1 shows a simple resource plan for an organization that runs online 
transaction processing (OLTP) applications and reporting applications simultaneously 
during the davtime. The currentlv active plan, DAYTIME, allocates CPU resources 
among three resource consumer groups. Specifically, OLTP is allotted ZS^ of the CPU 
time, REPORTS is allotted 15%, and OTHER_GROUPS receives the remaining 10%, 



Figure 25-1 A Simple Resource Plan 
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Oracle Database provides a procedure (CREATE_SIMPLE_PLAN) that enables you to 
quickly create a simple resource plan. This procedure is discussed in "Creating a 
Simple Resource Plan" on page 25-9, 

Note: The currently active resource plan does not enforce allocation 
limits until CPU usage is at 100%, If the CPU usage is below 100%, the 
database is not CPU-bound and hence there is no need to enforce 
limits to ensure that all sessions get their designated resource 
allocation. 

In addition, when limits are enforced, unused allocation bv any 
consumer group can be used by other consumer groups. In the 
previous example, if the OLTP group does not use all of its allocation, 
the Resource Manager permits the REPORTS group or OTHER_GR0UPS 
group to use the unused allocation. 

About Subplans 

Instead of referencing a consumer group, a resource plan directive (directi\'e) can 
reference another resource plan. In this case, the plan is referred to as a subplan. The 
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subplan itself has directives tliat allocate resources to consumer groups and other 
subplans. The resource allocation scheme then works like this: The lop resource plan 
(the currently active plan) divides resources among consumer groups and suhplans. 
Each subplan allocates its portion of the total resource allocation among its consumer 
groups and subplans. You can create hierarchical plans with anv number of subplans. 

You create a resource subplan in the same way that you create a resource plan. There 
is no difference between a plan and a subplan. A plan becomes a subplan onlv because 
you use it as such. 

Example: A Resource Plan with Subplans 

In this example, the Great Bread Company aUocates the CPU resource as shown in 
Figure 25-2. The figure illustrates a top plan (GREAT_BREAD) and all of its 
descendents. For simplicitv, the requirement to include the OTHER_GROUPS consumer 
group is ignored, and resource plan directives are not shown, even though thev are 
part of the plan. Rather, the CPU percentages that the directives allocate are shown 
along the connecting lines between plans, subplans, and consumer groups. 

Figure 25-2 A Resource Plan With Subplans 
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The GREAT_BREAD plan allocates resources as follows: 

■ 20% of CPU resources to the consumer group MARKET 

■ 60% of CPU resources to subplan SALES_TEAM, which in turn divides its share 
equally between the WHOLESALE and RETAIL consumer groups 

■ 20% of CPU resources to subplan DEVELOP_TEAM, which in turn divides its 
resources equally between the BREAD and MUFFIN consumer groups. 

It is possible for a subplan or consumer group to have more than one parent. An 
example would be if the MARKET group were included in the SALES_TEAM subplan. 
However, a plan cannot contain any loops. For example, the 3ALES_TEAM subplan 
carm.ot have a directive that references the GEEAT_BHEAD plan. 

See Also: "Putting It All Together: Oracle Database Resource 
Manager Examples" on page 25-31 for an example of a more complex 
resource plan. 



About Resource Allocation Methods 



Resource plan directives specify how resources are allocated to resource consumer 
groups or subplans. Each directive can specify a number of different methods for 
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allocating resources to its consumer group or subplan. The following sections 
summarize these resource allocation methods; 

CPU 

Active Session Pool with Queuing 

Degree of ParaUelism Limit 

Automatic Consumer Group Switching 

Canceling SQL and Terminating Sessions 

Execution Time Limit 

Undo Pool 

Idle Time Limit 

CPU 

This method enables you to specify how CPU resources are to be allocated among 
consumer groups and subplans. Multiple levels of CPU resource allocation (up to 
eight levels) provide a means of prioritizing CPU usage within a plan. Consumer 
groups and subplans at level 2 get resources that were not allocated at level 1 or w^ere 
not consumed bv a consumer group or subplan at level 1 . Similarly, resource 
consumers at level 3 are allocated resources onlv when some allocation remains from 
levels 1 and 2. The same rules apply to levels 4 through 8. Multiple levels not only 
provide a way of prioritizing, but thev provide a wav of explicitly specifying how all 
primary and leftover resources are to be used. 

See Figure 25-3 on page 25-33 for an example of a multilevel plan schema. 

Note: When there is only one level, unused allocation by any 
consumer group or subplan can be used by other consumer groups or 
subplans in the level. 

Active Session Pool with Queuing 

You can control the maximum number of concurrently active sessions allowed within 
a consumer group. This maximum defines the active session pool. An active session is 
a session that is in a call. It is considered active even if it is blocked, for example 
waiting for an I/O request to complete. When the active session pool is full, a session 
that is trving to process a call is placed into a queue. When an active session 
completes, the first session in the queue can then be removed from the queue and 
scheduled for execution. You can also specify a period after which a session in the 
execution queue times out, causing the call to terminate with an error. 

An entire parallel execution session is counted as one active session. 

This feature is useful if you want to limit the number of sessions in a consumer group 
that are competing for resources. For example, if a consumer group is used for 
processing long-running, parallel queries for reporting, you mav decide to limit the 
number of active sessions to one to allow one report to complete as quickly as possible, 
without competing with other reports for CPU or for parallel quer)' slaves. 

Degree of Parallelism Limit 

You can limit the maximum degree of parallelism for anv operation within a consumer 
group. This limit applies to one operation within a consumer group; it does not limit 
the total degree of parallelism across all operations within the consumer group. 
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However, you can combine both the degree of paralleUsm hmit and the active session 
pool features to achieve the desiied control. 

Automatic Consumer Group Switching 

This method enables you to control resource allocation bv specifying criteria that, if 
met, causes the automatic switching of a session to a specified consumer group. 
Tvpically, this method is used to switch a session from a high-priorit\' consumer 
group — one that receives a high proportion of system resources — to a lower priority 
consumer group because that session exceeded the expected resource consumption for 
a t\'pical session in the group. 

See "Specifying Automatic Switching by Setting Resource Limits" on page 25-22 for 
more information. 

Canceling SQL and Terminating Sessions 

You can also specifv directives to cancel long-running SQL queries or to terminate 
long-running sessions based on the amount of system resources consumed. See 
"Specifying Automatic Switching by Setting Resource Limits" on page 25-22 for more 
information. 

Execution Time Limit 

You can specify a maximum execution time allowed for an operation. If the database 
estimates that an operation will run longer than the specified maximum execution 
time, the operation is terminated with an error. This error can be trapped and the 
operation rescheduled. 

Undo Pool 

You can specifv an undo pool for each consumer group. An undo pool controls the 
total amount of undo for uncommitted transactions that can be generated bv a 
consumer group. When the total undo generated bv a consumer group exceeds its 
undo limit, the current DML statement generating the undo is terminated. No other 
members of the consumer group can perform further data manipulation until undo 
space is freed from the pool, 

Idielime Limit 

You can specify an amount of time that a session can be idle, after which it is 
terminated. You can also specify a more stringent idle time limit that applies to 
sessions that are idle and blocking other sessions. 

About Resource Manager Administration Privileges 

You must have the system privilege ADMIWISTER_RESOURCE_MAWAGER to 
administer the Resource Manager, This privilege (with the ADMIN option) is granted to 
database administrators through the DBA role. 

Being an administrator for the Resource Manager enables vou to execute all of the 
procedures in the DBMS_RESOURCE_MAWAGER PL/SQL package. 

You may, as an administrator with the ADMIN option, choose to grant the 
administrative privilege to other users or roles. This is possible using the 
DBMS_RESOURCE_MAWAGER_PRIVS PL/SQL package. The relevant package 
procedures are listed in the following table. 
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Procedure 


Description 




1 GRAHT_SYSTEM_PRIVILEGE 


Grants the SDMIHISTER_RESO0RCE_MAMAGER system 
privilege to a user or role. 




EEV"0KE_SY3 TEM_PRIVI LEGE 


Revokes the M}MIHISTER_RESOURCE_MAMAGER system 
privilege from a user or role. 





The following PL/SQL block grants the administrative privilege to user SCOTT, but 
does not grant SCOTT the ADMIN option. Therefore, SCOTT can execute all of the 
procedures in the DBMS_RESOURCE_MANAGER package, but SCOTT cannot use the 
GRAWT_SYSTEM_PRIVILEGE procedure to grant the administrative privilege to 
others. 

EEGIH 

DBMS_RESOURCE_MRNAGER_PEIVS . GRMT_SYSTEM_PEIVILEGE { 

GEANTEE_NME => 'SCOTT', 

PEIVILEGE_NfiME => 'RDMINISTER_RESOUECE_MANAGER' , 

RDMIN_OPTION => FALSE) ; 
END; 

You can revoke this privilege using the REVOKE_SYSTEM_PRVILEGE procedure. 

Note: The ADMINISTER_RESOURCE_MANAGER system privilege 
can only be granted or revoked using the 

DBMS_RESOURCE_MANAGER_PRIVS package. It cannot be granted 
or revoked through the SQL GRANT or REVOKE statements. 



See Also: Oracle Database PL/SQL Packages and Types Reference. 
contains detailed information about the Resource Manager 
packages: 

■ DBMS_RESOURCE_MANAGER 

■ DBMS RESOURCE MANAGER PRIVS 



Creating a Simple Resource Plan 



You can quickly create a simple resource plan that is adequate for many situations 
using the CREATE_SIMPLE_PLAN procedure. This procedure enables vou to both 
create consumer groups and allocate resources to them bv executing a single 
procedure call. Using this procedure, you are not required to invoke the procedures 
that are described in succeeding sections for creating a pending area, creating each 
consumer group individually, sp)ecifying resource plan directives, and so on. 

You specify the foUov/ing arguments for the CREATE_SIMPLE_PLAN procedure: 



Parameter 



Description 



SIMPLE_PLAM 
CONS DMER_GR0UP1 
GR0UP1_PERCEHT 
C0NSDMER_GROUP2 
GROUP 2_PERCEHT 
CONSUMER GR0UP3 



Name ot the plan 

Consumer group name for first group 
CPU resource allocated to this group 
Consumer group name for second group 
CPU resource allocated to this group 
Consumer group name for third group 
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Parameter 



Description 



GROUP 3_PERCENT 
CONS DMER_GE0UP4 
GE0UP4_PERCEMT 
C0NSDMER_GROUP5 
GROUP 5_PERCEHT 
C0NSUMER_GROUP 6 
GROUP 6_PERCEHT 
C0NSUMER_GROUP7 
GR0UP7_PERCEMT 
COnSUMER_GROUPB 
GROUPS PERCENT 



CPU resource allocated to this group 
Consumer group name for fourth group 
CPU resource allocated to this group 
Consumer group name for fifth group 
CPU resource allocated to this group 
Consumer group name for sixth group 
CPU resource allocated to this group 
Consumer group name for seventh group 
CPU resource allocated to this group 
Consumer group name for eighth group 
CPU resource allocated to this group 



You can specifv up to eight consumer groups with this procedure. The only resource 
allocation method supported is CPU. The plan uses the EMPHASIS CPU aUocation 
policy (the default) and each consumer group uses the ROUHD_ROBIN scheduling 
policy (also the default). Each consumer group specified in the plan is allocated its 
CPU percentage at level 2. Also implicitly included in the plan are SYS_GROUP (a 
system -de fined group that is the initial consumer group for the users SYS and 
SYSTEM) and OTHER_GROUPS, The SYS_GROUP consumer group is allocated lOCo of 
the CPU at leyel 1, and OTHER_GROUPS is allocated 100"u of the CPU at leyel 3. 

Example: Creating a Simple Plan with the CREATE_SIMPLE_PLAN Procedure 

The following PL/SQL block creates a simple resource plan with two user-specified 
consumer groups: 

BEGIH 

DBMS_RES0URCE_MMAGER.CREATE_3IMPI£_PLM[SIMPI^_PLAK => ' SfflPLE_PLANl ' , 

C01SUMER_GR0UP1 => 'MYGROUPl', GROUP 1_PERCENT => 80, 

C0HSUMER_GR0UP2 => 'MYGR0UP2', GR0UP2_PERCEHT => 20); 
END; 

Executing the preceding statements creates the following plan: 



Consumer Group 


Level 1 


Level 2 


Level 3 


SYS_GROUP 


100% 


- 


- 


MYGROUPl 


- 


80% 


- 


MYGR0UP2 


- 


20% 


- 


OTHER_GROUPS 


- 


- 


100% . 



See Also: 



"Creating a Resource Plan" on page 25-13 for more information on 
the EMPHASIS CPU allocation policy 

"Creating Resource Consumer Groups" on page 25-12 for more 
infoimation on the ROUND_ROBIN scheduling policy 

"Elements of the Resource Manager" on page 25-3 
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Creating a Complex Resource Plan 



When voiir situation calls for a more complex resource plan, vou must create the plan, 
with its directives and consumer groups, in a staging area called the pending area, and 
then validate the plan before storing it in the data dictionary. 

The following is a summarv of the steps required to create a complex resource plan. 
Note: A complex resource plan is anv resource plan that is not created 

with the DBMS_RESOURCE_MANAGER.CREATE_SIMPLE_PLAN 

procedure. 



Step 1: Create a pending area. 

Step 2: Create, modify, or delete consumer groups. 

Step 3: Create the resource plan. 

Step 4: Create resource plan directives. 

Step 5: Validate the pending area. 

Step 6: Submit the pending area. 

You use procedures in the DBMS_RESOURCE_MANAGER PL/SQL package to complete 
these steps. The following sections provide details: 

About the Pending Area 

Creating a Pending Area 

Creating Resource Consumer Groups 

Creating a Resource Plan 

Creating Resource Plan Directives 

Validating the Pending Area 

Submitting the Pending Area 

Clearing the Pending Area 

See Also: 

. DBMS_RESOURCE_MANAGER Package Procedures Summary 
on page 25-44 

■ Orach Database PL/SQL Packages and T\ipes Reference for details on 
the DBMS_RESOURCE_Ma.NAGER PL/SQL package. 



"Elements of the Resource Manager" on page 25-3 



About the Pending Area 



The pending area is a staging area where you can create a new resource plan, update 
an existing plan, or delete a plan without affecting currentlv running applications. 
When vou create a pending area, the database initializes it and then copies existing 
plans into the pending area so that thev can be updated. 
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Tip: After you create the pending area, if vou list aU plans by 
querying the DBA_RSRC_PLAWS data dictionarv view, you see Iwo 
copies of each plan: one with the PENDING status, and one without. 
The plans with the PENDING status reflect anv changes vou made to 
the plans since creating the pending area. Pending changes can also be 
viewed for consumer groups using DBA_R3RC_C0NSUMER_GR0UPS 
and for resource plan directives using 

DBA_R3RC_PLAH_DIRECTIVES. See Resource Manager Data 
Dictionarv Views on page 25-i5 for more information. 

After vou make changes in the pending area, you validate the pending area and then 
submit it. Upon submission, all pending changes are applied to the data dictionary', 
and the pending area is cleared and deactivated. 

If vou attempt to create, update, or delete a plan (or create, update, or delete consumer 
groups or resource plan directives) without first creating the pending area, you receive 
an error message. 

Submitting the pending area does not activate any new plan that you create; it just 
stores new or updated plan information in the data dictionan'. However, if you 
modifv a plan that is currently active, the plan is reactivated with the new plan 
definition. See "Enabling Oracle Database Resource Manager and Switching Plans" on 
page 25-30 for information about activating a resource plan. 

When you create a pending area, no other users can create one until vou submit or 
clear the pending area or log out. 

Creating a Pending Area 

You create a pending area with the CREATE_PENDING_AREA procedure. 

Example: Creating a pending area: 

The following PL/SQL block creates and initializes a pending area: 

BEGIH 

DfflS_HESOmCE_HMAGER.CREATE;_PENDIHG_RREA() ; 
END; 

Creating Resource Consumer Groups 

You create a resource consumer group using the CREATE_CONSUMER_GR0UP 
procedure. You can specifv the following parameters: 



Parameter Description 



CONSDMER_GROUP Name to assign to the consumer group. 

COMMEHT Any comment. 

CPU_MTH Deprecated. Use MGMT_MTH, 

MGMT_MTH The resource allocation method for distributing 

CPU among sessions in the consumer group. 
The default is ' ROUND-ROBIH ' , which uses a 
round-robin scheduler to ensure that sessions 
are fairly executed. ' RUN-TO-COMPLETIOH ' 
specifies that long-running sessions are 
scheduled ahead of other sessions. This setting 
helps long-running sessions (such as batch 
processes) complete sooner. 
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Example: Creating a Resource Consumer Group 

The following PL/SQL block creates a consumer group called OLTP with the default 
(ROUND-ROBIN) method of allocating resources to sessions in the group: 

BEGIH 
DBMS_RES0URCE_MftMAGER.CREaTE_COHS!MER_GR0OP ( 

COHSUMER_GROUP => 'OLTP', 

COMMENT => 'OLTP applications') r 

END; 



See Also: 

■ "Updating a Consumer Group" on page 25-36 

■ "Deleting a Consumer Group" on page 25-36 



Creating a Resource Plan 



You create a resource plan with the CREATE_PLAW procedure. You can specif\' the 
parameters shown in the following table. The first two parameters are required. The 
remainder are optional. 



Parameter 



Description 



PLAH 

COMMENT 

CPU_MTH 

ACTIVE_SESS_POOL_MTH 

PARALLEL_DEGREE_LrMIT_MTH 



QUEOEINGJITH 



MGMT MTH 



SUB PLAIl 



Name to assign to the plan. 
Any descriptive comment. 
Deprecated. Use MGMT_MTH. 

Active session pool resource allocation method. 

ACTIVE_SES3_POOL_ABgOLOTE is the default 
and only method available. 

Resource allocation method for specifj'ing a 
limit on the degree of parallelism of any 

operation, 

PARALLEL_DEGREE_LIMIT_ABgOLDTE is the 
default and only method available. 

Queuing resource allocation method. Controls 
the order in which queued inactive sessions are 
removed from the queue and added to the 
active session pool, FIF0_TIMEOUT is the 
default and only method available. 

Resource allocation method for specifying how 
much CPU each consumer group or subplan 
gets ' EMPHASIS ' , the default method, is for 
smgle-level or multilevel plans that use 
percentages to specify how CPU is distributed 
among consumer groups. 'RATIO' is for 
single-level plans that use ratios to specify how 
CPU is distributed. 

If TRDE, the plan cannot be used as the top plan; 
it can be used as a subplan only. Default is 
FALSE. 



Example: Creating a Resource Plan 

The following PL/SQL block creates a resource plan named DAYTIME: 



BEGIN 

DBMS_RBS0I1RCE_MMAGER . CREATE_PLAN ( 
PLAM => 'DAYTIME' , 
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COMMENT => 'More resources for OLTP applications'); 
END; 

About the RATIO CPU Allocation Method 

The RATIO method is an alternate CPU alJocation method intended for simple plans 
that have only a single level of CPU allocation. Instead of percentages, voii specify 
numbers corresponding to the ratio of CPU that you want to give to each consumer 
group. To use the RATIO method, vou set the MGMT_MTH argument for the 
CREATE_PLAN procedure to 'RATIO'. See "Creating Resource Plan Directives" on 
page 25-14 for an example of a plan that uses this method. 

See Also: 

■ "Updating a Plan" on page 25-36 

■ "Deleting a Plan" on page 25-36 



Creating Resource Plan Directives 



You use the CREATE_PLAN_DIRECTIVE procedure to create resource plan directives. 
You can specify the following parameters: 



Parameter 



Description 



PLAH 
GROUP_0R_SUBPLAM 

COMMENT 

CPU_P1 
CPU_P2 
CPU_P3 
CPU_P4 
CPU_P5 
CPU_P6 
CPU_P7 
CPU_P8 
ACTIVE SESS POOL PI 



QUEUEING_P1 



PARALLEL DEGREE LIMIT PI 



Name ot the resource plan to which the 
directive belongs. 

Name of the consumer group or subplan to 
which to allocate resourcES. 

Any comment 

Deprecated. Use MGMT_P1. 

Deprecated. UseMGMT_P2. 

Deprecated. Use MGMT_P3. 

Deprecated. UseMGMT_P4. 

Deprecated. Use MGMT_P5. 

Deprecated. Use MGMT_P6. 

Deprecated. Use MGMT_P7. 

Deprecated. Use MGMT_P8. 

Specifies the maximum number of concurrently 
active sessions for a consumer group. Other 
sessions await execution in an inactive session 
queue. Default is DMLIMITED. 

Specifies time [in seconds) after which a session 
in an inactive session queue (waiting for 
execution) times out and the call is aborted. 
Default is DHLIMITED. 

Specifies a limit on the degree of parallelism for 
any operation. Default is UNLIMITED. 
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Parameter 



Description 



SWITCH GROUP 



SWITCH TIME 



SWITCH ESTIMATE 



MAX EST EXEC TIME 



UMDO POOL 



MAX IDLE TIME 



MAX IDLE BLOCKER TIME 



SWITCH_T IME_IH_CALL 
MGMT PI 



MGMT P2 



MGMT P3 



Specifies the consumer group to which a session 
is switched if switch criteria are met. If the 
group name is 'CAMCEL_SQL', then the current 
call is canceled when switch criteria are met. If 
the group name is 'KILL_SESSIOH', then the 
session is killed when switch criteria are met. 
Default is HULL, 

Specifies the time (in CPU seconds) that a call 
can execute before an action is taken. Default is 
UMLIMITED. The action is specified by 
SWITCH_GROUP, 

If TRUE, the database estimates the execution 
time of each call, and if estimated execution 
time exceeds SWITCH_TIME, the session is 
switched to the SWITCH_GROUP before 
beginning the call. Default is FALSE. 

The execution time estimate is obtained from 
the optimizer The accuracy of the estimate is 
dependent on many factors, especially the 
quality of the optimizer statistics In general, 
you should expect statistics to be no more 
accurate than ± 10 minutes. 

Specifies the maximum execution time [in CPU 
seconds) allowed for a call. If the optimizer 
estimates that a call will take longer than 
MAX_EST_EXEC_TIME, the call is not allowed 
to proceed and ORA-07455 is issued. If the 
optimizer does not provide an estimate, this 
directive has no effect Default is UHLIMITED, 

The accuracy of the estimate is dependent on 
many factors, especially the quality of the 
optimizer statistics. In general, you should 
expect statistics to be no more accurate than ± 
10 minutes. 

Sets a maximum in kilobytes (K) on the total 
amount of undo for uncommitted transactions 
that can be generated by a consumer group. 
Default is UHLIMITED. 

Indicates the maximum session idle time, in 
seconds. Default is HULL, which implies 
unlimited. 

Indicates the maximum session idle time of a 
blocking session, in seconds. Default is NULL, 
which implies unlimited. 

Deprecated. Use SWITCH_FOR_CALL, 

For a plan with the MGMT_MTH parameter set to 
EMPHASIS, specifies the CPU percentage to 
allocate at the first level. For MGMT_MTH set to 
RATIO, specifies the weight of CPU usage. 
Default is HULL for allMGMT_Pn parameters. 

For EMPHASIS, specifies CPU percentage to 

allocate at the second level. Not applicable for 

RATIO. 

For EMPHASIS, specifies CPU percentage to 
allocate at the third level. Not applicable for 

RATIO. 
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Parameter 



Description 



MGMT P4 



MGHT P5 



MGMT P6 



MGMT P7 



MGMT P8 



SWITCH 10 MEGABYTES 



SWITCH_IO_REQS 



SWITCH FOR CALL 



For EMPHAS IS, specifies CPU percentage to 
allocate at the fourth level. Not applicable for 
RATIO. 

For EMPHAS IS, specifies CPU percentage to 
allocate at the fifth level. Not applicable for 
RATIO. 

For EMPHAS IS, specifies CPU percentage to 
allocate at the sixth level. Not applicable for 
RATIO. 

For EMPHASIS, specifies CPU percentage to 
allocate at the seventh level. Not applicable for 
RATIO. 

For EMPHAS IS, specifies CPU percentage to 
allocate at the eighth level. Not applicable for 
RATIO. 

Specifies the number of megabytes of I/O that a 
session can transfer (read and write) before an 
action is taken. Default is UMLIMITED. The 
action is specified by SWITCH_GRODP, 

Specifies the number of I/O requests that a 
session can execute before an action is taken. 
Default is UNLIMITED. The action is specified 
by SWITCH_GRODP. 

If TRUE, a session that was automatically 
switched to another consumer group (according 
to SWITCH_TIME, SWITCH_IO_MEGABYTES, or 
SWITCH_IO_REQS) is returned to its original 
consumer group when the top level call 
completes. Default is NULL, 



Example 1: 

The following PL/SQL block creates a resource plan directive for pliin DAYTIME, 
(Assumes that the DAYTIME plan and OLTP consumer group are already created in the 
pending area,) 

BEGIH 
DBMS_HESOmCE_HflKAGER.CREATE_PLAH_DIHECTIVE ( 

PLAH => 'DAYTIME' , 

GEOtrP_OR_SUBPLAM => 'OLTP', 

COMMENT => ' OLTP group ' , 

MGMT_P1 => 75) ; 

END; 

This directive assigns 75% of CPU resources to the OLTP consumer group at le\'^el 1, 

To complete the plan shown in Figure 25-1 on page 25-5, create the REPORTING 
consumer group, and then execute the following PL/SQL block: 

BEGIN 
DBMS_HESOURCE_MM]AGER.CREATE_PLAH_DIHECTIVE ( 

PLAH => 'DAYTIME', 

GROUP_OR_SUBPLAN => ' REPORTING ' , 

COMMENT => 'Reporting group', 

MGMT_P1 => 15, 

PftRALLEL_DEGREE_LIMIT_Pl => B, 

ACTIVE SESS POOL PI => 4) : 
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DBMS_HESOIIRCE_HftKAGER.CREATE_PLM_DIRECTIVE ( 

PLAN => 'DAYTIME', 

GROUP_OR_SUBPLAH => ' 0THER_GR0OP3 ' , 

COMMENT => 'This one is required', 

MGMT_P1 => 10); 

END; 

In this plan, consumer group REPORTING has a maximum degree of parallelism of 8 
for any operation, while none of the other consumer groups are limited in their degree 
of parallelism. In addition, the REPORTING group has a maximum of 4 concurrently 
active sessions. 

Example 2: 

This example uses the RATIO method to allocate CPU, which uses ratios instead of 
percentages. Suppose your application suite offers three service levels to clients: Gold, 
Silver, and Bronze. You create three consumer groups named GOLD_CG, SILVER_CG, 
and BRONZE_CG, and you create the following resource plan: 

BEGIN 

DEMS_RESOURCE_MRNAGER.CREATE_PLA[J 

(PLAN => 'SERVICE.LEVEL.PLM', 

MGMT_MTH => 'RATIO' , 

COMMENT => 'Plan that supports three service levels'); 

DBMS_RBSOIIRCE_HAKAGER . CEEATE_PLAF_DIRECTIVE 
(PLAN => 'SERVICE_LEVEL_PLAN', 

GR0UP_0R_3UBPLAN => 'GOLD_CG', 

COMMENT => 'Gold service level customers', 

MGMT_P1 => 10) ; 

DEMS_RESOURCE_MAKAGER . CREATE_PLAH_DIRECTIVE 
(PLAN => 'SERVICE_LEVEL_PLAN', 

GR0UP_0R_3UBPLAN => 'SILVER_CG', 

COMMENT => 'Silver service level customers', 

MGMT_P1 => 5) ; 

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE 
(PLAN => 'SERVICE_LEVEL_PLAN', 

GR0DP_0R_3UBPLAN => 'BRONZE_CG', 

COMMENT => 'Bronze service level customers', 

MGMT_P1 => 2 ) ; 

DBMS_RESOURCE_MAKAGER . CREATE_PLAH_DIRECTIVE 

(PLAN => 'SERVICE_LEVEL_PLAN', 

GR0UP_0R_3UBPLAN => ' O'fflER.GRODPS ' , 

COMMENT => 'Lowest priority sessions', 

MGMT_P1 => 1) r 

EHD; 

The ratio of CPU allocation is 10:5:2:1 for the GOLD_CG, SILVER_CG, BRONZE_CG, and 
OTHER_GR0UPS consumer groups, respectively. 

If sessions exist only in the GOLD_CG and SILVER_CG consumer groups, the ratio of 
CPU allocation is 10:5 between the tivo groups. 

How Resource Plan Directives Interact 

You may have occasion to reference the same consumer group from the top plan and 
any number of subplans. In this case, there are multiple resource plan directives that 
refer to the same consumer group, and the following rules apply: 
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The parallel degree limit for the consumer group will be the niiiiiiiiinii of all the 
incoming values. 

The active session pool for the consumer group will be the mni of all the incoming 
values and the queue timeout will be the in'miiiiiiiu of all incoming timeout values. 

The undo pool for the consumer group will be the sum of aU the incoming values. 

If there is more than one SWITCH_TIME, SWITCH_IO_MEGABYTES, or 
SWITCH_IO_REQS, Oracle Database Resource Manager (the Resource Manager) 
chooses the most restrictive of all incoming values. Specifically: 

- SWITCH_TIME =min (all incoming SWITCH_TIME values) 

SWITCH_IO_MEGABYTES = min (all incoming SWITCH_IO_MEGABYTES 

values) 

SWITCH_IO_REQS = min (all incoming SWITCH_IO_REQS values) 

- SWITCH ESTIMATE = TRUE overrides SWITCH ESTIMATE = FALSE 



Note: If both plan directives specif)' the same switch time, but 
different switch groups, then the choice as to which group to switch 
to is statically but arbitrarily decided by the Resource Manager, 



SWITCH_FOR_CALL is TRUE if any of the incoming values are TRUE. 

The maximum estimated execution time will be the most restrictive of all Lncoming 
values. Specifically: 

MAX_EST_EXEC_TIME = min (all incoming MAK_EST_EXEC_TIME values) 

The maximum idle time is the minimum of all incoming values. 

The maximum idle blocker time is the miiiimiim of all incoming values. 

See Also: 

■ "Updating a Resource Plan Directive" on page 25-37 

■ "Deleting a Resource Plan Directive" on page 25-37 



Validating the Pending Area 



At anv time when von are making changes in the pending area, vou can call 
VALIDATE_PEWDIWG_AREA to ensure that the pending area is valid so far. 

The following rules must be adhered to, and are checked by the validate procedure: 

■ No plan can contain any loops. A loop occurs when a subplan contains a directive 
that references a plan that is above the subplan in the plan hierarchv. For example, 
a subplan cannot reference the top plan. 

■ All plans and resource consumer groups referred to by plan directives must exist, 

■ All plans must have plan directives that point to either plans or resource consumer 
groups. 

■ All percentages in any given level must not add up to greater than 100. 

■ A plan that is currently being used as a top plan bv an active instance cannot be 
deleted. 
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■ The following parameters can appear only in plan directives that refer to resource 
consumer groups, not other resource plans: 

- paeallel_degree_limit_p1 

- active_sess_p00l_p1 

- queueiwg_p1 

- switch_group 

- switc;h_time 

- switch_estimate 

- switch_io_reqs 

- switch_io_megabytes 

- max_est_exec_time 

- uwdo_pool 

- max_idle_time 

- max_idle_blogker_time 

- switch_for_call 

■ There can be no more than 31 resource consumer groups in any active plan. Also, 
at most, a plan can have 31 children, 

■ Plans and resource consumer groups cannot have the same name. 

■ There must be a plan directive for OTHER_GROUPS somewhere in anv active plan. 
This ensures that a session that is not part of any of the consumer groups included 
in the currently active plan is allocated resources (as specified by the directive for 

OTHER_GROUPS). 

VALIDATE_PEWDIWG_AREA raises an error if anv of the preceding rules are violated. 
You can then make changes to fix any problems and call the procedure again. 

It is possible to create "orphan" consumer groups that have no plan directives referring 
to them. This allows the creation of consumer groups that will not currently be used, 
but might be part of some plan to be implemented in the future. 

Example: Validating the Pending Area: 

The following PL/SQL block validates the pending area. 

BEGIN 

DBMS_BBSOI)RCE_MMAGER.VM,IDATE_PENDING_AHEA() ; 
END; 

See Also: "About the Pending Area" on page 25-11 



Submitting the Pending Area 



After you have validated your changes, call the SUBMIT_PENDING_AREA procedure 
to make your changes active. 

The submit procedure also performs validation, so you do not necessarily need to 
make separate calls to the validate procedure. However, if vou are making major 
changes to plans, debugging problems is often easier if you incrementally validate 
your changes. No changes are submitted (made active) until validation is successful on 
all of the changes in the pending area. 
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The SUBMIT_PENDING_AREA procedure dears (deactivates) the pending area after 
successfully validating and committing the changes. 



Note: A call to SUBMIT_PENDING_AREA might fail even if 
VALIDATE_PE]srDING_AREA succeeds. This can happen if, for 
example, a plan being deleted is loaded bv an instance after a call to 
VALIDATE_PENDING_AREA, but before a call to 

SUBMIT PENDING AREA. 



Example: Submitting the Pending Area: 

The following PL/SQL block submits the pending area: 

BEGIH 

DBMS_RESDURCE_MflKAGER.SUBMIT_PMDING_AEEfi() ; 
END; 

See Also: "About the Pending Area" on page 25-11 



Clearing the Pending Area 



There is also a procedure for clearing the pending area at any time. This PL/SQL block 
causes aU of your changes to be cleared from the pending area and deactivates the 
pending area: 



BEGIH 

DBMS_HE30mCE_HflKAGER.CLEflE_PENDIHG_AREA[] ; 
END; 

After calling CLEAR_PENi:iNG_AREA. you must call the CREATE_PENDING_AREA 
procedure before vou can again attempt to make changes. 

See Also: "About the Pending Area" on page 25-11 

Assigning Sessions to Resource Consumer Groups 

This section describes the automatic and manual methods that database 
administrators, users, and applications can use to assign sessions to resource 
consumer groups. When a session is assigned to a resource consumer group, Oracle 
Database Resource Manager (the Resource Manager) can manage resource allocation 
for it. 

Note: Sessions that are not explicitly assigned an initial consumer group 
are placed in the consumer group DEFAULT_CONSUMER_GROUP. 

This section includes the following topics: 

Overview of Assigning Sessions to Resource Consumer Groups 

Assigning an Initial Resource Consumer Group 

Manually Switching Resource Consumer Groups 

Specifying Automatic Resource Consumer Group Switching 

Specifving Session- to-Consumer Group Mapping Rules 

Enabling Users or Applications to Manually Switch Consumer Groups 
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■ Granting and Revoking the Switch Privilege 

Overview of Assigning Sessions to Resource Consumer Groups 

Before vou enable the Resource Manager, you must specify how user sessions are 
assigned to resource consumer groups. You do this bv creating iiiapping rules that 
enable the Resource Manager to automatically assign each session to a consumer 
group upon session startup, based upon session attributes. After a session is assigned 
to its initial consumer group and is running, vou can call a procedure to manuallv 
switch the session to a different consumer group. You would tj'pically do this if the 
session is using excessive resources and must be moved to a consumer group that is 
more limited in its resource allocation. You can also grant the swifcli privilege to users 
and to applications so that thev can switch their sessions from one consumer group to 
another. 

The database can also automatically switch a session from one consumer group to 
another (tvpically lower priority) consumer group when there are changes in session 
attributes or when a session exceeds designated resource consumption limits. 

Assigning an Initial Resource Consumer Group 

The initial consumer group of a session is determined bv the mapping rules that vou 
configure. For information on how to configure mapping rules, see "Specifving 
Session- to-Consumer Group Mapping Rules" on page 25-24, If no mapping rule 
applies for a new session, the default consumer group for the session is specified bv 
the IWITIAL_RSRC_CONSUMER_GROUP attribute of the user who started the session. 
You can view the value of this attribute bv viewing the 
IWITIAL_RSRC_COWSUMER_GROUP column in the *-_USER views. 

Manually Switching Resource Consumer Groups 

The DBMS_RBSOURCB_MAIIAGBR PL /SQL package provides two procedures that 
enable vou to change the resource consumer group of running sessions. Both of these 
procedures can also change the consumer group of any parallel execution sen'er 
sessions associated with the coordinator session. The changes made by these 
procedures pertain to current sessions onlv; they are not persistent. They also do not 
change the initial consumer groups for users. 

Instead of killing (terminating) a session of a user who is using excessive CPU, you can 
change that user's consumer group to one that is allocated fewer resources. 

Switching a Single Session 

The SWITCH_C0NSUMER_GR0UP_F0R_3ESS procedure causes the specified session to 
immediately be moved into the specified resource consumer group. In effect, this 
procedure can raise or lower priority of the session. 

The following PL /SQL block switches a specific session to a new consumer group. The 
session identifier (SID) is 17, the session serial number (SERIALtt) is 12345, and the 
new consumer group is the HIGH_PRIORITY consumer group. 

BEGIN 

DfflS_RES0URCE_MMAGER.SWITCH_COHSI)MER_GR0DP_FOR_SESS { ' 17 ' , '12 345' , 

'HIGH_PRIORITY') ; 
END; 

The SID, session serial number, and current resource consumer group for a session are 
viewable using the V$ SESSION view. 
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See Also: Oracle DafflbflseRe^reiicc for details about the V$ SESSION 
view. 

Switching Ali Sessions for a User 

The SWITCH_G0HSUMER_GR0UP_F0R_U3ER procedure clianges the resource 
consumer group for all sessions pertaining to the specified user name. The following 
PL/SQL block switches all sessions that belong to user SCOTT to the LOW_GROUP 
consumer group: 

BEGIN 

DBMS_HES0URCE_MMAGER.SWITCH_COH3UMER_GR0DP_FOE_USER {'SCOTT' , 

' L0W_GRODP ' ) ; 
END; 

Specifying Automatic Resource Consumer Group Switching 

You can configure the Resource Manager to automatically switch a session to another 
consumer group when a certain condition is met. Automatic switching can occur 
when: 

■ A session attribute changes, causing a new mapping rule to take effect. 

■ A session exceeds the CPU or I/O resource consumption limits set by its consumer 
group. 

The following sections provide details: 

■ Specifving Automatic Switching with Mapping Rules 

■ Specifving Automatic Switching by Setting Resource Limits 

Specifying Automatic Switciiing witli Mapping Rules 

If a session attribute changes while the session is running, the session-to-consumer 
group mapping rules are ree\'aluated, and if a new rule takes effect, the session might 
be moved to a different consumer group. See "Specifying Session-to-Consumer Group 
Mapping Rules" on page 25-24 for more information. 

Specifying Automatic Switciiing by Setting Resource Limits 

When you create a resource plan directive for a consumer group, vou can specifv 
hmits for CPU and I/O resource consumption for sessions in that group. You do so by 
specifving the action that is to be taken if any single call within a session exceeds one 
of these limits. The possible actions are the following: 

■ The session is dvnamically switched to a designated consumer group. 

The target consumer group is tvpically one that has lower resource allocations. 
The session's user must have switch pn'vikgcs on the new consumer group, 
otherwise the switch cannot occur See "Granting and Revoking the Switch 
Privilege" on page 25-28 for more information. 

■ The session is killed (terminated). 

■ The session's current SQL statement is aborted. 

The following are the resource plan directive attributes that are involved in this type 
of automatic session switching. 

■ SWITCH_GROUP 

■ SWITCH TIME 
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■ switch_estimate 

■ switch_io_megabytes 

■ switc;h_io_reqs 

■ SWITC;H_FOR_C;aLL 

See "Creating Resource Plan Directives" on page 25-14 for descriptions of these 
attributes. 

Switches occur for sessions that are running and consuming resources, not waiting for 
user input or waiting for CPU cvcles. The switclied session is allowed to continue 
running even if the acti\'e session pool for the new group is full. Under these 
conditions, a consumer group can have more sessions running than specified by its 
active session pool. 

SWITCH_FOE_CALL is useful for three-tier applications where the middle tier server is 
using session pooling. A top call in PL/SQL is an entire PL/SQL block treated as one 
call. A top call in SQL is an individual SQL statement. 

The following are examples of automatic switching based on resource limits; 

Example 1: 

The following PL/SQL block creates a resource plan directive for the OLTP group that 
switches anv session in that group to the LOM_GROUP consumer group if a call in the 
sessions exceeds 5 seconds of CPU time. This example prevents unexpectediv long 
queries from consuming too many resources. The switched-to consumer group is 
typicaUy one with lower resource allocations, 

BEGIN 

DBMS_HESOmCE_HMAGER.CREATE_PLAK_DIRECTIVE ( 

PLAN => 'DAYTIME' , 

GROUP_OR_SUBPLAH => 'OLTP', 

COMMENT => ' OLTP group ' , 

MGMT_P1 => 75, 

SWITCH_GROUP => ' L0W_GRODP ' , 

SMITCe_TIME => 5}; 
EHD; 

Example 2 

The following PL/SQL block creates a resource plan directive for the OLTP group that 
temporarily switches any session in that group to the LOM_GROUP consumer group if 
the session exceeds 10,000 I/O requests or exceeds 2,500 Megabvtes of data 
transferred. The session is returned to its original group after the offending top call is 
complete, 

BEGIH 
EBMS_HESOURCE_MRNAGER.CKEATE_PLAH_DIRECTIVE [ 

PLAH => 'DAYTIME' , 

GROtrP_OR_SUBPLAH => ' OLTP ' , 

COMMENT => ' OLTP group ' , 

HGMT_P1 => 75, 

SWITCH_GROUP => ' LOW_GROUP ' , 

SWITCH_IO_REQS => lOOQO, 

SMITCH_I0_MEGaB¥TE3 => 2500, 

SWITCH_FOR_CALL => TRUE) ; 
EHD; 
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Example 3: 

The following PL/SQL block creates a resource plan directive for the OLTP group that 
kills (terminates) anv session that exceeds 60 seconds of CPU time. This example 
prevents runaway queries from consuming too many resources. 

BEGIH 
DBMS_RESOIIHCE_MMAGER.CREaTE_PLM_DIRECTIVE ( 

PLAN => 'DAYTIME' , 

GROUP_OR_SUBPLAH => 'OLTP', 

COMMENT => ' OLTP group ' , 

MGMT_P1 => 75, 

SWITCH_GROUP => 'KILL_SESSIOH', 

SMITCH_TIME => 60) ; 
END; 

See Also: "Creating Resource Plan Directives" on page 25-14 

Specifying Session-to-Consumer Group Mapping Rules 

This section provides background information about session-to-consumer group 
mapping rules, and describes hovv' to create and prioritize them. The following topics 
axe covered: 

■ About Session-to-Consumer Group Mapping Rules 

■ Creating Consumer Group Mapping Rules 

■ Creating Mapping Rule Priorities 

About Session-to-Consumer Group Mapping Ruies 

By creating session-to-consumer group mapping rules, vou can: 

■ Specifv the initial consumer group for a session based on session attributes. 

■ Enable the Resource Manager to dynamically switch a running session to another 
consumer group based on changing session attributes. 

The mapping rules are based on session attributes such as the user name, the service 
that the session used to connect to the database, or the name of the client program. 

To resolve conflicts among mapping rules, the Resource Manager orders the rules by 
priorit;'. For example, suppose user SCOTT connects to the database with the SALES 
service. If one mapping rule states that user SCOTT starts in the MED_PRIORITY 
consumer group, and another states that sessions that connect with the SALES service 
start in the HIGH_PRLORLTY consumer group, mapping rule priorities resolve this 
confhct. 

There are two tvpes of session attributes upon which mapping rules are based: login 
attributes and runtime attributes. The login attributes are meaningful onlv at session 
login time, when the Resource Manager determines the initial consumer group of the 
session. In contrast, a session that has alreadv logged in can later be reassigned to 
another consumer group based on its changing run-time attributes. 

You use the SET_CONSUMER_GROUP_MAPPING and 

SET_CONSUMER_GROUP_MAPPING_PRI procedures to configure the automatic 
assigning of sessions to consumer groups. You must use a pending area for these 
procedures, (You must create the pending area, run the procedures, optionally 
validate the pending area, and then submit the pending area. For examples of using 
the pending area, see "Creating a Complex Resource Plan" on page 25-11,) 
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A session is aiitoniatically switched to a consumer group tlirough mapping rules at 
distinct points in time: 

■ When the session first logs in, the mapping rules are evaluated to determine the 
initial group of the session, 

■ If a session attribute is dynamically changed to a new value (which is only 
possible for runtime attributes), the mapping rules are reevaluated and the session 
might be switched to another consumer group. 

Two things to note about the preceding rules are the following: 

■ If a runtime attribute for which a mapping rule is provided is set to the same value 
that it already has, no switching takes place, 

■ A session can be switched to the same consumer group it is already in. The effect 
of switching in this case is to initialize to zero the session statistics that are 
typically initialized during a switch to a different group. An example of such a 
statistic is the ACTIVE_TIME_IW_GROUP value of the session. 

See Also: 

■ "Assigning an Initial Resource Consumer Group" on page 25-21 

■ "Specifj'ing Automatic Switching with Mapping Rules" on 
page 25-22 

Creating Consumer Group Mapping Ruies 

The mapping rules for a session consist of a set of iiltribule/ consumer group pairs that 
determine how a session is matched to a consumer group. You use the 
SET_COWSUMEE_GEOUP_MAPPIWG procedure to map a single session attribute to a 
consumer group. The parameters for this procedure are the following: 



Parameter 



Description 



ATTRIBUTE 

VaLUE 

CONSUMER GROUP 



The login or runtime session attribute type, 
spet:ified as a package constant 

The value of the attribute being mapped 

The consumer group to map to 



ATTRIBUTE can be one of the following: 



Attribute 



Type 



Description 



ORACLE_USER 
SERVICE NAME 



CLIEHT OS USER 



CLIEHT PROGRAM 



CLIEHT MACHINE 



Logm The Oracle Database user name 

Login The service name used by the cUent to estabUsh a 

connection 

Login The operating system user name of the client that 

is logging in 

Login The name ot the client program used to log in to 

the server 

Login The name of the computer from which the client 

is makine the connection 



MODULE NAME 



Runtime The module name in the currently running 
application as set by the 

DBMS_APPLICATlbN_INFO.SET_MODULE 
procedure or the equivalent OCX attribute setting 
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Attribute Type Description 



M0DULE_HAME_ACTIOH Runtime A combination of the current module iind the 

iiction being performed as set by either of the 
following procedures or their equivalent OCI 
attribute setting: 

■ DBMS_APPLICATIOH_IHFO.SET_MODULE 

■ DBMS_APPLICATI0H_IHF0.3ET_ACTIOH 

The attribute is specified as the module name 
followed by a period [.), followed by the action 
name (module_name . actio;i_rjanie). 

SERVICE_MODULE Runtime A combination of service and module nam.es in 

this form: service_naiae .module_name 

SERVICE_MODULE_ACTION Runtime A combination of service name, module name, 

and action name, in this form: 
service name. module name. action name 



For example, the following PL/SQL block causes user SCOTT to map to the 
DEV_GROUP consumer group ever}' time that he logs in: 

BEGIH 
DBMS_HESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPIHG 

(Dffl3_RE30UECE_MAHAGER.0RACLE_U3ER, 'SCOTT', ' DEV_GROUP ' ) ; 
END; 

Again, you must create a pending area before running the 

SET_CONSUMER_GROUP_MAPPING procedure. 

Creating Mapping Rule Priorities 

To resolve conflicting mapping rules, you can establish a priority ordering of the 
session attributes from most important to least important. You use the 
gET_CONSUMER_GROUP_MAPPING_PRI procedure to set the priority of each attribute 
to a unique integer from 1 (most important) to 10 (least important). The follovi'ing 
example illustrates this setting of priorities: 

BEGIH 
DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPIHG_PRI( 

EXPLICIT => 1, 

SERVICE_MODULE_ACTION => 2, 

SERVICE_MODULE => 3, 

MODULE_NAME_ACTIO[J => 4, 

MODULE_NAME => 5, 

SERVICE_HAME => 5, 

ORACLE_USER => 7, 

CLIENT_PROGRAM => 8, 

CLIENT_OS_USER => 9, 

CLIENT_MACHIHE => lO); 
END; 

In this example, the prioritv of the database user name is set to 7 (less important), 
while the priorit}' of the module name is set to 5 (more important). 
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Note: SET_CONSUMER_GROUP_MAPPING_PRI requires thatyou include 
the pseudo-attribute EXPLICIT as an argument. It must be set to 1, It 
indicates that explicit consumer group switches have the highest priority. 
You explicitly switch consumer groups with these package procedures, 
which are described in detail in Oracle Database PL/SQL Packages and Types 
Reference: 

m DBMS_SESSION. SWITCH_CURRENT_CONSUMER_GROUP 

■ DBMS_RESOURCE_MANAGER . SWITCH_CONSUMER_GROUP_FOR_SESS 

■ DBMS_RESOURCE_MANAGER . SWITCH_CONSUMER_GROUP_FOR_USER 

To illustrate how mapping rule priorities work, assume that in addition to the 
mapping of user SCOTT to the DEV_GROUP consumer group, there is also a module 
name mapping rule as follows: 

BEGIN 

DBMS_HESOURCE_MMAGER.SET_CONSUMER_GROUP_MAPPIHG 

iDBM3_RE30USCE_MAHAGER.M0DULE_HAHE, 'BACKUP', ' LOM_PRIORITY' ) ; 
EKD; 

Now if user SCOTT's session sets its module name to BACKUP, the session is reassigned 
to the LOW_PRIORITY consumer group, because module name mapping has a higher 
priority than database user mapping. 

You can query the view DBA_RSRC_MAPPING_PRIORITY to see the current priority- 
ordering of session attributes. 

To prevent unauthorized clients from setting their session attributes so that they map 
to higher priorit}' consumer groups, user switch privileges for consumer groups are 
enforced. Thus, even though the attribute of a particular session matches a mapping 
pair, the mapping rule is ignored if the session does not have the switch privilege for 
the designated consumer group. 

Enabling Users or Applications to Manually Switch Consumer Groups 

You can grant a user the switch privilege so that he can switch his current consumer 
group using the SWITCH_CURREHT_COHSUMER_GROUP procedure in the 
DBMS_SESSION package. A user can run this procedure from an interactive session, 
for example from SQL*Plus, or an application can call this procedure to switch its 
session, effectively dynamicallv changing its prioritv'. 

The SWITCH_CURREHT_CONSUMER_GROUP procedure enables users to switch to only 
those consumer groups for which they have the switch privilege. If the caller is 
another procedure, then this procedure enables users to switch to a consumer group 
for which the owner of that procedure has switch privileges. 

The parameters for this procedure are the following: 

Parameter Description 

NEW_CONSDMER_GR0UP The consumer group to which the user is 

switching. 

0LD_CONSDMER_GR0UP Returns the niime of the consumer group from 

which the user switched. Can be used to switch 
back later. 
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Parameter Description 



IHITIAL_GR0UP_0H_EEEOR Controls behavior if a switching error occurs. 

If TRUE, in the event of an error, the user is 
switched to the initial consumer group. 

If FALSE, raises an error. 

The following SQL'Plus session illustrates switching to a new consumer group. Bv 
printing the value of the output parameter old._group, the example illustrates how 
the old consumer group name is saved. 

SET server output on 
DECLARE 

old._group varchar2 (30) ; 
BEGIH 

DBMS_SESSION.SWITCH_CUEEENT_COHSUMER_GEOUPCOLTP', old_group, FALSEj ; 
DBMS_OUTPUT.PUT_LINE( 'OLD GROUP = ' || old_group) ; 
END; 
/ 

The follov/ing line is output: 

OLD GROUP = DEFAULT_CONSUMER_GROUP 

Note that the Resource Manager considers a switch to have taken place even if the 
SWITCH_CURRENT_CONSUMER_GROUP procedure is called to switch the session to the 
consumer group that it is already in. 

Note: The Resource Manager also works in environments where a 
generic database user name is used to log on to an application. The 
DBMS_SESSION package can be called to switch the consumer 
group assignment of a session at session startup, or as particular 
modules are called. 



See Also: Oracle Database PL/SQL Packages and Types Reference for 
additional examples and more information about the 

DBMS_SESSION package 

Granting and Revoking the Switch Privilege 

Using the DBMS_RESOURCE_MAHAGER_PRIVS PL/SQL package, you can grant or 
revoke the switch privilege to a user, role, or PUBLIC. The switch privilege enables a 
user or application to switch a session to a specified resource consumer group. It also 
enables the database to automatically switch a session to a consumer group specified 
in a session-to-consumer group mapping rule or specified in the SWITCH_GROUP 
parameter of a resource plan directive. The package also enables vou to revoke the 
switch privilege. The relevant package procedures are listed in the following table. 

Procedure Description 



GRAHT_SWITCH_COHSUMER_GROUP Grants permission to a user, role, or PUBLIC to switch to a 

specified resource consumer group. 



REV0KE_SWITCH_C0NSUMER_GROUP Revokes permission for a user, role, or PUBLIC to switch to a 

specified resource consumer group. 
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DEFAULT_COWSUMEE_GEOUP has switch privileges granted to PUBLIC, Therefore, all 
users are automatic ally granted the switch privilege for this consumer group. 

See Also: 

■ "Enabling Users or Applications to Manually Switch Consumer 
Groups" on page 25-27 

■ "Specifying Automatic Resource Consumer Group Switching" on 
page 25-22 

Granting the Switch Privilege 

The following example grants user SCOTT the privilege to switch to consumer group 
OLTP. 

BEGIN 

DBMS_HBS0I1HCE_MMAGER_PRIVS . GRMT_SWITCH_C0HSUMER_GRODP ( 

GRANTEE_NaME => 'SCOTT'. 

COHSUMER_GROUP => 'OLTP', 

GRANT_OPTIOH => TRUE) ; 
END; 

User SCOTT is also granted permission to grant switch privileges for OLTP to others. 

If you grant permission to a role to switch to a particular resource consumer group, 
then anv user who is granted that role and has enabled that role can switch his session 
to that consumer group. 

If you grant PUBLIC the permission to switch to a particular consumer group, then 
any user can switch to that group. 

If the GRAWT_OPTION argument is TRUE, then users granted switch privilege for the 
consumer group can also grant switch privileges for that consumer group to others. 

Revolting Switch Privileges 

The following example revokes user SCOTT's privilege to switch to consumer group 

OLTP. 

BEGIN 

DBMS_HBSOIIRCE_MftNAGER_PRIVS .REVOKE_SWITCH_COHSUMER_GROUP ( 

REVOKEE_NME => 'SCOTT', 

CONSUMER_GRODP => ' OLTP ' ) ; 
EHD; 

If vou revoke a user's switch privileges for a particular consumer group, anv 
subsequent attempts bv that user to switch to that consumer group fail. If you revoke 
the switch privilege for the initial consumer group from a user, that user is 
automatically assigned to the DEFAULT_CONSUMER_GROUP upon login. 

If vou revoke from a role the switch privileges to a consumer group, any users who 
had switch privileges for the consumer group only through that role are no longer able 
to switch to that consumer group. 

If vou revoke switch privileges to a consumer group from PUBLIC, any users other 
than those who are explicitly assigned switch privileges either directly or through a 
role are no longer able to switch to that consumer group. 
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Enabling Oracle Database Resource Manager and Switching Plans 

You enable Oracle Database Resource Manager (the Resource Manager) by setting the 
RESOUECE_MAWAGEE_PLAW initialization parameter. This parameter specifies the top 
plan, identifying the plan to be used for the current instance. If no plan is specified 
with this parameter, the Resource Manager is not activated. 

By default the Resource Manager is not enabled. 

The following statement in a text initialization parameter file actiyates the Resource 
Manager upon database startup and sets the top plan asmYdb_plan. 

EESODRCE_iaNAGER_PLM = mydbjlan 

You can also activate or deactivate the Resource Manager, or change the current top 
plan, using the DBMS_RES01IRCE_MAWAGER. SWITCH_PLAW package procedure or the 
ALTER SYSTEM statement 

The following SQL statement sets the top plan to mydb_plan, and activates the 
Resource Manager if it is not already active: 

ALTER SYSTEM SET HESODRCE_MMAGER_PLAN = 'mydb_plan ' ; 

An error message is returned if the specified plan does not exist in the data dictionary. 

Automatic Enabling of the Resource Manager by Oracle Scheduler Windows 

The Resource Manager automatically activates if an Oracle Scheduler window that 
specifies a resource plan opens. When the Scheduler window closes, the resource plan 
associated with the window is disabled and the resource plan that was running before 
the Scheduler window opened is reenabled. (If no resource plan was enabled before 
the window opened, the Resource Manager is disabled again when the window 
closes.) In an Oracle Real Application Clusters environment, a Scheduler window 
applies to all instances, so the window's resource plan is enabled on everv instance. 

Note that bv default a set of automated maintenance tasks run during maintenance 
window^s, which are predefined Scheduler windows that are members of the 
MAIWTEWAWCE_WIWDOW_GROUP window group and which specify the 
DEFAULT_MAIWTEWAWCE_PLAN resource plan. Thus, the Resource Manager activates 
by default during maintenance windows. 

See Also: 

■ "Windows" on page 26-9 

■ Chapter 24, "Managing Automated Database Maintenance Tasks" 

Disabling Plan Switches by Oracle Scheduler Windows 

In some cases, the automatic change of Resource Manager plans atScheduler window 
boundaries mav be undesirable. For example, if vou have an important task to finish, 
and if vou set the Resource Manager plan to give your task priorit;', then you expect 
that the plan will remain the same until vou change it. However, because a Scheduler 
window could activate after vou have set your plan, the Resource Manager plan might 
change while vour task is running. 

To prevent this situation, you can set the HESOUHCE_MAHAGER_PLAM initialization 
parameter to the name of the plan that vou want for the system and prepend 
"force ; " to the name, as shown in the following SQL statement: 

ALTER SYSTEM SET RESOURCE_HfflAGER_PLAH = 'FORCE:raydbjilan' ; 
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Using the prefix FORCE : indicates that the current resource plan ciin be changed onlv 
when the database administrator changes the value of the RE SOURCE_MANAGER_PLAN 
initiaUzation parameter This restriction can be lifted bv rerunning the command 
witliout preceding the plan name with "FORCE : ". 

The DBMS_RESOURCE_MAMAGER . SWITCH_PLAM package procedure has a simUar 
capability. 

See Also: Oracle Database PL/SQL Packages and Types Reference for 
more information on DBMS_RESOURCE_M&NAGER . SWITCH_PLAM. 

Disabling the Resource Manager 

To disable the Resource Manager, complete the foUowing steps: 

1. Issue the following SQL statement: 

ALTER SYSTEM SET RESOUECE_HAHAGER_PLM = ' ' ; 

2. Disassociate the Resource Manager from all Oracle Scheduler windows. 
To do so, for any Scheduler window that references a resource plan in its 

resource_plan attribute, use the DBMS_SCHEDULER . SET_ATTRIBUTE 
procedure to set re3ource_plan to the emptv string ("}. Qualify the window 
name with the SYS schema name if you are not logged in as user SYS. You can 
view Scheduler windows with the DBA_SCHEDULER_WINDOWS data dictionar;' 
view. See "Altering Windows" on page 27-25 and Oracle Database PL/SQL Packages 
and Types Reference for more information. 

Note: By default, all maintenance window^s reference the 

DEFAULT_MAINTENaNCE_PLaN resource plan. If you want to 
completely disable the Resource Manager, you must alter all 
maintenance windows to remove this plan. However, use caution, 
because resource consumption by automated maintenance tasks will 
no longer be regulated, which may adversely affect the performance 
of your other sessions. See Chapter 24, "Managing Automated 
Database Maintenance Tasks" for more information on maintenance 
windows. 

Putting It All Together: Oracle Database Resource Manager Examples 

This section provides some examples of resource plans. The following examples are 
presented: 

■ Multilevel Plan Example 

■ Example of Using Several Resource Allocation Methods 

■ An Oracle-SuppUed Mixed Workload Plan 

Multilevel Plan Example 

The following PL/SQL block creates a multilevel plan as illustrated in Figure 25-3 on 
page 25-33, Default resource allocation method settings are used for all plans and 
resource consumer groups. 

BEGIN 

DBMS_RESOUKCE_MANAGER.CHEATE_PKNDING_AREan ; 
DBMS_SiESOURCE_MANAGER.CREATE_PLRN(PLAN => ' bugdb_plail ' . 

COMMEHT => 'Resource plan/method for bug users sessions'): 
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DEMS_RESODRCK_MAnAGER.CKEATE_PLAN(PLAN =5 ■iDalldb_plail ' , 

COMMEHT => "Resource plan /method for mail users sessions'); 
DEMS_RESODRCK_MAnAGER.CREATE_PLAN(PLAN =5 ■iDydb_plail ' , 

COMMEHT => "Resource plan /method for bug and raaLl users sessions'); 
DEMS_RESODRCK_MAnAGER.CREATE_COKSUMER_GROUP ( CONSUME R_GROUP == ' Online_group ' . 

COMMEHT => "Resource consumer group/raethod for online bug users sessions'): 
DEMS_RESODRCK_MAnAGER.CREATE_COKSUHEH_GROUP ( CONSUME R_GROUP =s ' Bat ch_g roup " , 

COMMEHT => "Resource consumer group/raethod for batch job bug users sessions"); 
DBMS_RESODRCK_MAnAGER.CREATE_COKSUHER_GROUP ( CONSUME R_GROUP == ' Bug_Maint_group " , 

COMMEHT => "Resource consumer group/raethod for users sessions for bug db inaint'); 
DEMS_RESODRCE_MAnAGER.CREATE_COKSUMER_GROUP ( CONSUME R_GROUP == 'Users_group ' , 

COMMEHT => "Resource consumer group/raethod for mail users sessions"); 
DEMS_RESODRCK_MAnAGER.CREATE_COKSUMER_GROUP ( CONSUME R_GROUP => ' Postnian_group ' , 

COMMEHT => "Resource consumer group/raethod for mail postman'); 
DBMS_RESODRCE_MAnAGER.CREATE_COKSUHER_GROUP ( CONSUME R_GROUP => ' Mai l_Haint_g roup ' , 

COMMEHT => "Resource consumer group/raethod for users sessions for mail db inaint"); 
DEMS_KESODRCE_MAnAGER.CREATE_PLAN_DIRECTIVE (PLAN =? ' bugdb_plan ' , 

GR0UP_OR_SDBPLFiK => " Online_group ' , 

COMMENT => "online bug users sessions at level 1", MGMT_P1 =5 SO, MGMT_P2=> 0); 
DEMS_RESODRCE_MAnAGER.CREATE_PLAN_DIRECTIVE (PLAN => 'bugdb_plan' , 

GROUP _OR_SDBP LAN => " Batch_group ' , 

COMMENT => "batch bug users sessions at level 1', MGMT_Pi =5 20, MGMT_P3 =5 0, 

PARALLEL_DEGREE_LIMIT_P1 => S); 
DEMS_RESODRCE_MAnAGER.CREATE_PLAN_DIRECTIVE (PLAN =? ' bugdb_plan ' , 

GROUP _OR_SDBP LAN => " Bug_Maint_group ' , 

COMMENT => "bug maintenance users sessions at level 2", MGMT_P1 =? 0, MGMT_P2 =? 100); 
DBMS_RESODRCE_MAnAGER.CREATE_PLAN_DIRECTIVE (PLAN =? ' bugdb_plan ' , 

GR0UP_OR_SUBPLAN => " 0'raER_GROUPS ' , 

COMMENT == "all other users sessions at level 3", MGMT_Pi =5 0, MGMT_P2 =5 0, 

MGMT_P3 => 100) ; 
DBMS_RESODRCE_MAnAGER.CREATE_PLAN_DIRECTIVE (PLAN =? 'raaildb_plan " , 

GROUP _OR_SDBP LAN => " Pos tman_group " , 

COMMENT => "mail postman at level 1', MGMT_P1 =? 40, MGMT_P2 => 0); 
DBMS_RESODRCE_MAnAGER.CREATE_PLAN_DIRECTIVE (PLAN =? 'raaildb_plan " , 

GROUP _OR_SDBP LAN => ' Users_group ' , 

COMMENT => 'mail users sessions at level 2', MGMT_P1 => 0, MGMT_P2 => 80); 
DBMS_RESODRCE_MAnAGER.CREATE_PLAN_DIRECTIVE (PLAN =? 'raaildb_plan " , 

GROUP _OR_SDBP LAN => "Mail_Maint_gr oup ' , 

COMMENT => 'mail maintenance users sessions at level 2', MGMT_P1 => 0, MGMT_P2 => 20); 
DBMS_RESODRCE_MAnAGER.CREATE_PLAN_DIRECTIVE (PLAN =? 'raaildb_plan " , 

GR0UP_OR_SUEPLAN => " 0'raER_GROUPS ' , 

COMMENT == "all other users sessions at level 3", MGMT_Pi =5 0, MGMT_P2 =s 0, 

MGMT_P3 => 100) ; 
DBMS_RESODRCE_MAnAGER.CREATE_PLAN_DIRECTIVE (PLAN =? 'raydb_plan ' , 

GR0UP_OR_SUBPLAN => "maildb_plan ' , 

COMMENT== 'all mail users sessions at level 1', MGMT_P1 => 30); 
DBMS_KESODRCE_MAnAGER.CREATE_PLAN_DIRECTIVE (PLAN =? 'raydb_plan ' , 

GROUP _OR_SDBP LAN => " bugdb_plan ' , 

COMMENT => "all bug users sessions at level 1', MGMT_P1 => 70); 
DBMS_RESODRCE_MAnAGER. VALIDATE_PENDIKG_AREA( ) ; 
DBMS_RESOURCE_MAnAGER.SUBMIT_PEKDING_AREA() ; 
END; 

The preceding call to VALIDATE_PENDING_AREA is optional because the validation is 
implicitly performed in SUBMIT_PEWDIWG_AREA. 
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Figure 25-3 Multilevel Plan Schema 




In this plan schema, CPU resources are allocated as follows: 

■ Under mYdb_pl an, 30% of CPU is allocated to the maild.b_plan subplan, and 
70% is allocated to the bugdb_plan subplan. Both subplans are at level 1. Because 
mYdb_plan itself has no levels below level 1, any resource allocations that are 
unused by either subplan at level 1 can be used bv its sibling subplan. Thus, if 
maildb_plan uses only 20% of CPU, then 80% of CPU is available to 
bugdb_plan. 

■ maildb_plan defines allocations at levels 1, 2, and 3, and bugdb_plan defines 
allocations at levels 1 and 2. The levels in these subplans are independent of levels 
in their parent plan, mYdb_plan, That is, all plans and subplans in a plan schema 
have their own level 1, level 2, level 3, and so on, 

. Of the 30% of CPU allocated to maildb_plan, 40% of that amount (effectively 
12% of total CPU) is allocated to Postman_group at level 1. Because 
Postman_group has no siblings at level 1, there is an implied 60% remaining at 
level 1. This 60% is then shared by User3_group andMail_Maint_group at 
level 2, at 80% and 20%, respectively. In addition to this 60%, Users_group and 
Mail_Maint_group can also use any of the 40'*o not used by Postman_group at 
level 1. 

■ CPU resources not used by either UEers_group or Mail_Maint_group at level 
2 are allocated to OTHER_GROUPS, because in multilevel plans, unused resources 
are reallocated to consumer groups or subplans at the next lower level, not to 
siblings at the same level. Thus, if U3ers_group uses only 70% instead of 80%, 
the remaining lO^i. cannot be used by Mail_Maint_group. That 10% is available 
only to OTHER_GROUPS at level 3. 

Example of Using Several Resource Allocation Methods 

The example presented here could represent a plan for a database supporting a 
packaged ERP (Enterprise Resource Planning) or CRM (Customer Relationship 
Management) application. The work in such an environment can be highly varied. 
There may be a mix of short transactions and quick queries, in combination with 
longer running batch jobs that include large parallel queries. The goal is to give good 
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response time to OLTP (Online Transaction Processing), whUe allowing batch jobs to 
run in parallel. 



The plan is summarized in the following table. 



Maximum 
CPU Estimated 
Resource Active Session Automatic Consumer Execution 
Group Allocation % Pool Parameters Group Switching Time 


Undo Pool 


oltp 


Level 1: 80% 




Switch to group: batch 
Switch time: 3 sees 




200K 


batch 


Level 2: 100% 


Pool size: 5 
Timeout: 600 sees 


— 


3600 sees 


— 


OTHER_GROtJPS 


Level 3: 100% 


- 


- 




- 



By assigning only 80% of the CPU to oltp at level 1, batch is guaranteed to get at 
least ZO^o, plus any of oltp's unused CPU resources, OTHER_GROUPS, however, is not 
guaranteed any CPU resources. It gets CPU resources only if batch is unable to 
consume all of its allocation, A similar-looking plan would give oltp 80% and batch 
20^0, both at levell, and 0THER_GR0UP3 100% at level 2, With this plan, oltp's 
unused CPU allocation would be given to OTHER_GROUPS, not batch. 

The following statements create the preceding plan, which is named erp_plan: 

BEGIH 

DBMS_RESOURCE_MM]AGER.CREATE_PENDING_AEEA() ; 
DBMS_RESOURCE_MM]AGER.CREATE_PLM(PLM => 'erp_plan', 

COfflEHT => 'Resource plan/method for ERP Database'); 
DBMS_RES0URCE_MM]AGER.CREATE_C0HS(MER_GR0UP(COH3UMER_GR0UP => 'oltp', 

COMMEHT => 'Resource cons-unier group /method for OLTP jobs'); 
DBMS_RES0URCE_MM]AGER.CREATE_C0HS(MER_GR0UP(COH3UMER_GR0UP => 'batch', 

COMMENT => 'Resource conEuiner group/method for BATCH jobs'); 
DBMS_RESOURCE_MM]AGER.CREATE_PLAH_DIRECTIVE{PLAM => 'erp_plan', 

GROUP_OR_SnBPLAM => 'oltp', COMMENT => 'OLTP sessions', MGHT_P1 => 80, 

3WITCH_GR0UP => 'batch', SMITCH_TIME => 3, UMD0_P0OL => 200); 
DBMS_RESOURCE_MM]AGER.CREATE_PyUJ_DIRECTIVE{PLAM => 'erp_plan', 

GROUP_OR_SnBPLAM => 'batch', COMMENT => 'BATCH sessions', MGMT_P2 => 100, 

ACTIVE_3ESS_P00L_P1 => 5, QUEUEIHG_P1 => 500, MftX_EST_EXEC_TIME => 3600); 
DBM3_RES0URCE_MM]AGER.CEEATE_PLAH_DIRECTIVE(PLAM => 'erp_plan', 

GROUP_OR_SnBPLAM => ' OTHER_GROUPS ' , COMMENT => 'mandatory', MGMT_P3 => 100); 
DBM3_RES0URCE_MMAGER.VALIDATE_PEM)ING_AREA{) ; 
DBM3_RES0URCE_MMAGER.SnBMIT_PENDIKG_AEEA() ; 
END; 



An Oracle-Supplied Mixed Workload Plan 



Oracle Database includes a predefined resource plan, MIXED_WORKLOAD_PLAN, that 
prioritizes interactive operations over batch operations, and includes the required 
subplans and consumer groups recommended by Oracle. MIXED_WORKLOAD_PLAN is 
defined as follows: 



Group orSubplan 


CPU Resource Allocation 


' Automatic Consumer Group 
Level 1 Level 2 Level 3 Switching 


Max Degree of 
Parallelism 


BATCH_GRODP 


100% 1 
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CPU Resource Allocation 




Group or Subplan 


Levell 


Level 2 


Level 3 


Automatic Consumer Group 
Switching 


Max Degree of 
Parallelism 


IHTERACTIVE_GROUP 




85% 




Switch to group: BATCH_GROUP 
Switch time: 60 seconds 
Switch for call: TRUE 


1 


0RASAUTOTASK_SUB_PLAH 




5% 








ORASD I AGNOSTICS 




5% 








OTHER_GROUPS 




5% 








SYS_GROUP 


100% 











In this pliin, because INTERACTIVE_GEOUP is intended for short transactions, anv call 
that lasts longer than 60 seconds is automatically switched to BATCH_GROUP, which is 
intended for longer batch operations. 

You can use this predefined plan if it is appropriate for vour environment. (You can 
modif}" the plan, or delete it if vou do not intend to use it.) Note that there is nothing 
special about the names BATCH_GROUP and IWTEEACTIVE_GROUP. The names reflect 
only the intended purposes of the groups, and it is up to you to map application 
sessions to these groups and adjust CPU resource allocation percentages accordingly 
so that vou achieve proper resource management for your interacti\e and batch 
applications. For example, to ensure that your interactive applications run under the 
IWTEEACTIVE_GEOUP consumer group, vou must map your interactive applications' 
user sessions to this consumer group based on user name, service name, program 
name, module name, or action, as described in "Specifying Session-to-Consumer 
Group Mapping Rules" on page 25-24, You must map vour batch applications to the 
BATCH_GROUP in the same wav, Finallv, vou must enable this plan as described in 
"Enabling Oracle Database Resource Manager and Switching Plans" on page 25-30, 

See Table 25-1 on page 25-43 and Table 25-2 on page 25-43 for explanations of the 
other resource consumer groups and subplans in this plan. 



Maintaining Consumer Groups, Plans, and Directives 

This section provides instructions for maintaining consumer groups, resource plans, 
and resource plan directives for Oracle Database Resource Manager (the Resource 
Manager), You perform maintenance tasks using the DBMS_RESOURCE_MAWAGER 
PL/SQL package. The following topics are covered: 

Updating a Consumer Group 

Deleting a Consumer Group 

Updating a Plan 

Deleting a Plan 

Updating a Resource Plan Directive 

Deleting a Resource Plan Directive 
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See Also: 



DBMS_RESOURCE_MANAGER Package Procedures Summary 
on page 25-44 

Oracle Database PL/SQL Packages and Types Reference for details on 
the DBMS_RESOURCE_MANAGER PL/SQL package. 



Updating a Consumer Group 



You use the UPDATE_COWSUMER_GROUP procedure to update consumer group 
information. The pending area must be created first, and then submitted after the 
consumer group is updated. If you do not specify the arguments for the 
UPDATE_COWSUMEE_GEOUP procedure, they remain unchanged in the data dictionary. 



Deleting a Consumer Group 



The DELETE_CONSUMER_GROUP procedure deletes the specified consumer group. The 
pending area must be created first, and then submitted after the consumer group is 
deleted. Upon deletion of a consumer group, all users having the deleted group as 
their initial consumer group are assigned the DEFAULT_CONSUMER_GROUP as their 
initial consumer group. All currently running sessions belonging to a deleted 
consumer group are assigned to a new consumer group, based on the consumer group 
mapping rules. If no consumer group is found for a session through mapping, the 
session is switched to the DEFAULT CONSUMER GROUP, 



You carmot delete a consumer group if it is referenced by a resource plan directive. 



Updating a Plan 



You use the UPEATE_PLAN procedure to update plan information. The pending area 
must be created first, and then submitted after the plan is updated. If you do not 
specify the arguments for the UPDATE_PLAW procedure, they remain unchanged in the 
data dictionary. The following PL/SQL block updates the COMMENT parameter, 

BEGIH 

DfflS_HESOURCE_MMAGER . UPDATEJLAH ( 

PIAH => 'DAYTIME' , 

NEW_COMMENT => '50'* more resources for OLTP applications'); 
END; 



Deleting a Plan 



The DELETE_PLAN procedure deletes the specified plan as well as all the plan 
directives associated with it. The pending area must be created first, and then 
submitted after the plan is deleted. 

The following PL/SQL block deletes the grea.t_brea.d plan and its directives, 

BEGIH 

DBMS_RESOmCE_MMAGER.DELETE_PLAN|PLAN => ' great_bread' ) ; 

END; 

The resource consumer groups referenced by the deleted directives are not deleted, 
but they are no longer associated with the great_bread plan. 

The EBLBTE_PLAM_CASCADB procedure deletes the specified plan as weU as all its 
descendants: plan directives and those subplans and resource consumer groups that 
are not marked by the database as mandator^'. If DELETE_PLAN_CASCADE encounters 
an error, it rolls back, leaving the plan unchanged. 
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You cannot delete the ciirrentlv active plan. 



Updating a Resource Plan Directive 



Use the UPDATE_PLAN_DIRECTIVE procedure to update plan directives. The pending 
area must be created first, and then submitted after the resource plan directive is 
updated. If you do not specif)' the arguments for the UPDATE_PLAN_DIRECTIVE 
procedure, they remain unchanged in the data dictionary. 

Deleting a Resource Plan Directive 

To delete a resource plan directive, use the DELETE_PLAN_DIRECTIVE procedure. 
The pending area must be created first, and then submitted after the resource plan 
directive is deleted. 

Viewing Database Resource Manager Configuration and Status 

You can use a number of static data dictionary views and dynamic performance views 
to view tlie current configuration and status of Oracle Database Resource Manager 
(the Resource Manager). This section provides the following examples; 

■ Viewing Consumer Groups Granted to Users or Roles 

■ Viewing Plan Information 

■ Viewing Current Consumer Groups for Sessions 

■ Viewing the Currently Active Plans 

See Also: Oracle Database Referenee for details on all static data 
dictionary views and dynamic performance views 

Viewing Consumer Groups Granted to Users or Roles 

The DBA_R3RC_C0NSUMER_GR0UP_PRIVS view displays the consumer groups 
granted to users or roles. Specifically, it displays the groups to which a user or role is 
allowed to belong or be switched. For example, in the view shown below, user SCOTT 
always starts in the SALES consumer group, can switch to the MARKETING group 
through a specific grant, and can switch to the DEFAULT_COWSUMER_GROUP and 
LOW_GROUP groups because they are granted to PUBLIC. SCOTT also has the ability to 
grant the SALES group but not the MARKETING group to other users. 

S2L> SELECT ' FROM DBA_RSRC_CONSUHER_GROnP_PHIVS ; 



GRANTEE 


GHANTED_GROUP 


GRANT 


_OPTIOH 


INITIAL_GROUP 


PUBLIC 


DEFAULT CONSUMER GROUP 


YES 




YES 


PUBLIC 


LOW GROUP 


BO 




NO 


SCOTT 


MARKETING 


NO 




NO 


SCOTT 


SALES 


YES 




YES 


SYSTEM 


SYS GROUP 


HO 




YES 



SCOTT was granted the ability to switch to these groups using the 

DBMS_RESOURCE_MANAGER_PRIVS package. 
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Viewing Plan Information 



This example uses the DBA_RSRC_ PLANS view to display all of the resource plans 
defined in the database. All plans have a NULL status, meaning that they are not in the 
pending area. 

Note: Plans in the pending area have a status of PENDING. 



S2L> SELECT PLAN, COMMEHTS, STATUS FROM DBA_RSRC_PLM3 ; 
PLAN COMMENTS 



STimis 



MIXED_WOHKLOAD_PLAN 

0RA$AUTOTASK_SUB_PLAH 

0RA$AUTOTASK_HIGH_SnB_PLAH 

ERP_PLAN 

DEFAULT_PLAN 

IHTERNAL_QtriESCE 

IHTERMAL_PLM 

DEFAULT MAINTEHAHCE PLM 



Example plan for a mixed workload that prio 
Default sub-plan for automated maintenance 
Default suli-plan for high-priority, auttmat 
Resource plan/method for ERP Database 
Default, basic, pre-defined plan that prior 
Plan for quiescing the database. This plan 
Internally-used plan for disabling the reso 
Default plan for maintenance windows that p 



Viewing Current Consumer Groups for Sessions 

You can use the VS SESSION view to display the consumer groups that are currently 
assigned to sessions. 

SeL> SELECT SID,SERIAL#,USERHAHE,RES0URCE_C0N3UMER_GR0UP FROM VSSESSIOH; 
SID SERIAL* USERMAME RESOURCE CONSUMER GROUP 



11 
13 



136 SYS 
16570 SCOTT 



SYS_GRODP 
SALES 



Viewing tlie Currently Active Plans 



This example sets mydb_plan. as created by the example shown earlier in "Multilevel 
Plan Example" on page 25-31, as the top level plan. It then queries the VSR3RC_PLAN 
view to display the currenth' active plans. The \'iew displays the current top level plan 
and all of its descendent subplans. 

S2L> ALTER SYSTEM SET RESOURCE_MANAGER_PLM = mydb_plan; 

System altered. 

SeL> SELECT NAME, IS_TOP_PLAH FROM V3RSRC_PLAN; 



NAME 



IS TOP PLM 



MYDB_PLAN 
MAILDB_PLAK 
BUGDB PLAN 



TRUE 

FALSE 

FALSE 
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Monitoring Oracle Database Resource Manager 

Use the following d\'ni"imic performance views to help you monitor the results of your 
Oracle Database Resource Manager settings; 

. V$RSRC_PLAN 

. V$RSRC_CONSUMER_GROUP 

. V$RSRC_SESS10N_1NF0 

. V$RSRC_PLAN_HISTORY 

. V$RSRC_CONS_GROUP_HlSTORY 

These views provide: 

■ Current status information 

■ History of resource plan activations 

■ Current and historical statistics on resource consumption and CPU waits by both 
resource consumer group and session 

In addition, historical statistics are available through the DBA_H I ST_RSRC_PLAW and 
DBA_HIST_ESEC_COWSUMEE_GEOUP views, which contain Automatic Workload 
Repository (AWR) snapshots of the V5RSRC_PLAN_HI STORY and 

VSRSEC_COWS_GEOUP_HISTOEY, respectively. 

For assistance with tuning, the views V$RSRCMGRMETRIC and 

VSRSECMGEMETEIC_HISTOEY show how much time was spent waiting for CPU and 
how much CPU was consumed per minute for every consumer group for the past 
hour These metrics can be viewed graphicallv with Enterprise Manager, on the 
Resource Manager Statistics page. 

V$RSRC_PLAN This view displays the currentlv active resource plan and its 
subpians. 

SELECT name, iE_top_plan FROM v5rsrc_plarir 
HAME IS_TOP_PLM 



DEFAULT_PLM TRUE 

DRASAUT0TASK_3UB_PIAM FALSE 

DEASAUTOTASK_HIGH_SnB_PLAN FALSE 



The plan for which I S_TOP_PLAN is TRUE is the currently active (top) plan, and the 
other plans are subpians of either the top plan or of other subpians in the list. 

VSRSRC_CONSUMER_GROUP Use the VSRSRC_CONSUMER_GROUP view to monitor 
CPU usage and CPU waits. It provides the cumulative amount of CPU time 
consumed, cumulative amount of time waiting for CPU, and cumulative number of 
CPU waits bv all sessions in each consumer group. It also provides a number of other 
measures helpful for tuning. 

SQL> SELECT name, active_sesaionE , !jue"ue_lengt±L, 
conaiiraed._cpu_time, cpu_waits, cpu_wait_time 
EROM vSrsrc_consuiiier__group; 

HAME ACTIVE_SESSIOHS QUEUE_IZNGTH COHSlMED_CPtr_TIME CPU_WAITS CPD_1AIT_TIME 

OLTP_ORDER_ENTRY 

OTHER GROUPS 
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1 





29590 


467 


6709 








5982366 


4089 


60425 



Moniloring Oracle Database Resource Manager 



SYS_GROUP 

DSS_QUERIES 



2420704 
4594560 



914 
3004 



19540 
55700 



111 the preceding query results, the DSS_QUERIES consumer group has four sessions 
in its active session pool and two more sessions queued for activation. 

A key measure in this view is CPU_WAIT_TIME, This indicates the total time that 
sessions in the consumer group waited for CPU because of resource management. Not 
included in this measure are waits due to latch or enqueue contention, I/O waits, and 
so on. 



V$RSRC_SESSION_INFO Use this view to monitor the status of one or more 
sessions. The view shows how the session has been affected by the Resource Manager. 
It provides information such as: 

The consumer group that the session currently belongs to. 

The consumer group that the session originally belonged to. 

The session attribute that was used to map the session to the consumer group. 

Session state (RUNNING, MAIT_FOR_CPU, QUEUED, and so on). 

Current and cumulative statistics for metrics, such as CPU consumed, wait times, 
and queued time. Current statistics reflect statistics for the session since it joined 
its current consumer group. Cumulative statistics reflect statistics for the session in 
all consumer groups to which it has belonged since it was created, 

SQL> 3EI£CT se.sid seES_id, co.naine consuiner_group, 
se. state, se.con3umed_cpu_time cpu_time, se.cpu_wait_time, se . queued_time 
FROM vSrsrc_sessioii_info se, v$rsrc_conEumer_group co 
WHERE se . current_conEumer_group_id = co.id; 



SE3S ID COHSUMER GROUP 



STATE 



CPU_TIME CPU_WAIT_TIME QUEUED.TIME 



113 OLTP_ORDER_ENTRY WAITING 
135 OTHER_GROUPS 
124 OTHER_GROUPS 

114 SYS_GROUP 
102 SYS_GROUP 
147 D3S_QUERIES 



WAITING 


137947 


IDLE 


785659 


WAITING 


50401 


RUNNING 


495 


IDLE 


88054 


WAITING 


460910 



28845 
11126 
14326 



512154 



CPU_WAIT_TIME in this view has the same meaning as in the 
VSRSRC_CONSUMER_GROUP view, but applied to an individual session. 

VSRSRC_PLAN_HISTORY This view shows when resource plans were enabled or 
disabled on the instance. Each resource plan activation or deactivation is assigned a 
sequence number For each entry in the view, the VSRSRC_CONS_GROUP_HI STORY 
view has a corresponding entry for each consumer group in the plan that shows the 
cumulative statistics for the consumer group. The two views arejoined by the 
SEQUENCE* column in each. 

SQL> SELECT sequencet seq, name plan_name, 
to_char|start_time, 'DD-MON-YY HH24:MM'} start_tme, 
to_char(end_tme, 'DD-MON-YY HH24 ;MM' ) erid_tijiie, window_name 
FROM vSrsrc_plan_history; 



SEQ PLRH_NME 



START TIME 



END TIME 



WINDOW NAME 



2 DEFAULT MAINTENANCE PLAN 



29-MAY-07 23:05 29-MAY-07 23:05 

29-MAY-07 23:05 30-MAY-07 02:05 TUESDAY WINDOW 
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4 DEFAULT_MAIHTENMCE_PLM 

5 

6 DEFAULT MAIHTENAHCE PLM 



30-MAY-07 02:05 30-HftY-07 22:05 

30-MAY-07 22:05 31-MftY-07 02:05 WEDNESDAYS IHDOW 

31-MAY-07 02:05 31-MAY-07 22:05 

31-MAY-07 22:05 THURSDAY WINDOW 



A null value under PLAN_NAME indicates that no plan was active. 

AWR snapshots of this view are stored in the DBA_HIST_RSRC_PLAH view. 

V$RSRC_CONS_GROUP_HI STORY This view helps you understand how resources 
were shared among the consumer groups over time. The sequencett column 
corresponds to the column of the same name in the V$RSRC_PLAN_HI STORY view. 
This enables you to determine the plan that was active for each row of consumer 
group statistics. 

SQL> select sequence! seq, name, cpu_wait_time, cp"u_waits, 
consiimed_cpu_tiiiie from VSRSRC_C0HS_GROUP_HI3T0EY; 



SEQ NAME CPU_ 


_WAIT_TIME 


CPUJAITS 


CONSDMED_CPD_TIME 


2 SYS_GROUP 


18133 


691 


33364431 


2 OTHER_GEOUPS 


51252 


825 


181058333 


2 ORA$AUTOTASK_MEDIUM_GROUP 


21 


5 


4019709 


2 ORA$AUTOTASK_UEGENT_GROUP 


35 


1 


198760 


2 0RA$AUT0TASK_STATS_GROUP 











2 0RA$AUT0TASK_SPACE_GROUP 











2 0RA$AUT0TASK_S2L_GE0UP 











2 ORA$AUTOTASK_HEALTH_GROUP 











2 ORA$ DIAGNOSTICS 








1072678 


4 SYS_GROUP 


40344 


85 


42519265 


4 OTHER_GEOUPS 


123295 


1040 


371481422 


4 ORA$AUTOTASK_MEDIUM_GROUP 


1 


4 


7433002 


4 ORA$AUTOTASK_UEGENT_GROUP 


22959 


158 


19964703 


4 0RA$AUT0TASK_STATS_GROUP 












6 ORA$ DIAGNOSTICS 

AWR snapshots of this view are stored in the DBA_HIST_RSRC_CONSUMER_GROUP 

view. Use DBA_HIST_RSRC_CONSUMEE_GROUP with DBA_HIST_RSRC_PLAH to 

determine the plan that was active for each historical set of consumer group statistics. 

See Also: 

■ Oracle Database Reference for information on these and other 
Resource Manager views, 

■ Oracle Database Performance Tuning Guide for information about the 
AWR, 

Interacting with Operating-System Resource Control 

Many operating systems provide tools for resource management. These tools often 
contain "workload manager" or "resource manager" in their names, and are intended 
to allow multiple applications to share the resources of a single server, using an 
administrator-defined policy. Oracle Database expects a static configuration and 
allocates internal resources, such as latches, from available resources detected at 
database startup. The database might not perform optimally and can become unstable 
if operating svstem resource configuration changes frequently. 
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Guidelines for Using Operating-System Resource Control 

If voLL do choose to use Operating- system resource control with Oracle Database, then 
you must use it judiciously, according to the following guidelines: 

1 . In general, operating system resource control should not be used concurrently 
with Oracle Database Resource Manager (the Resource Manager), because neither 
of them are aware of each other's existence. As a result, both the operating svstem 
and the Resource Manager trv to control resource allocation in a manner that 
causes unpredictable behavior and instabiiit\' of Oracle Database. 

■ If vou v/ant to control resource distribution within an instance, use the 
Resource Manager and turn off operating-system resource control. 

■ If vou have multiple instances on a node and you want to distribute resources 
among them, use op era ting- system resource control, not the Resource 
Manager. 



Note: Oracle Database currently does not support the use of both 
tools simultaneouslv. Future releases might allow for their 
interaction on a limited scale, 

2. If vou decide to use an operating system resource manager (such as Hewlett 
Packard's Process Resource Manager or Sun's Solaris Resource Manager) 
concurrentlv with Oracle Database Resource Manager (the Resource Manager), 
you must ensure that all of the following conditions are met; 

■ Each database instance must be assigned to a dedicated opera ting-svstem 
resource manager group or managed entit\'. 

■ The dedicated entity running all the instance's processes must run at one 
priority (or resource consumption) level, 

■ The CPU resources assigned to the dedicated entity cannot be changed more 
frequently than once everv few minutes, 

■ Process priority management must not be enabled. 

Caution: Management of individual datiihase processes at 
different priorit\' levels (for example, using the nice command on 
UNIX platforms) is not supported. Severe consequences, including 
instance crashes, can result. You can expect similar undesirable 
results if op era ting- system resource control is permitted to manage 
the memorv to which an Oracle Database instance is pinned, 

3. If you decide to use operating system resource control only, ensure that vou turn 
off the Resource Manager, See "Disabling the Resource Manager " on page 25-31 for 
instructions. 

Oracle Database Resource Manager Reference 

The following sections provide reference information for Oracle Database Resource 
Manager (the Resource Manager): 

■ Predefined Resource Plans and Consumer Groups 

. DBMS_RESOURCE_MANAGER Package Procedures Summary 
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■ Resource Manager Data Dictionar\' Views 

Predefined Resource Plans and Consumer Groups 

Table 25-1 lists the resource plans and Table 25-2 lists the resource consumer groups 
that are predefined for each Oracle database. 



Table 25-1 Predefined Resource Plans 



Resource Plan 


Description 


DEFAULT MAINTENANCE PLAN 


Default plan for maintenance windows. See "About Resource 




Allocations for Automated Maintenance Tasks" on page 24-3 for 




details of this plan. 


DEFAULT PLAN 


Basic default plan that prioritizes SYS_GROUP operations and 




allocates minimal resources for automated maintenance and 




diagnostics operations. 


IHTERMAL_PLAN 


For disabling the resource manager. For internal use only. 


INTERHAL_QUIESCE 


For tjiiiescing the database. This plan cannot be activated 




directly. To activate, use the QUIESCE command. 


MIXED WORKLOAD PLAN 


Example plan for a mixed workload that prioritizes interactive 




operations over batch operations. See "An Oracle-Supplied 




Mixed Workload Plan" on page 25-34 for details. 


ORASAUTOTASK HIGH SUB PLAN 


Default sub-plan for high-prior it\', automated maintenance 




tasks. This sub-plan is referenced bv 




ORASAUTOTASK SUB PLAN and should not be referenced 




directly. This plan is a sub-plan of 




DEFAULT_MAINTEHANCE_PLAH. 


ORASAUTOTASK SUB PLAH 


Default sub-plan for automated maintenance tasks. A directive 




to this sub-p an should be included in every top-level plan to 




m.anage the resources consumed by the automated maintenance 




tasks. This plan is a sab-plan of 




DEFAULT_MAINTEHANCE_PLAH. 



Table 25-2 Predefined Resource Consumer Groups 



Resource Consumer Group 


Description 


BATCH_GROUP 




Consumer group for batch operations. 


DEFAULT_C0NSUMER_GROUP 


Initial consumer group for all sessions started by user accounts 
other than SYS and SYSTEM. This initial consumer group can be 
overridden by session-to-consumer group mapping rules. 
DEFAULT_cdHSUMER_GROUP cannot be named in a resource 
plan directive. 


INTERACTIVE_GROUP 




Consumer group for interactive, OLTP operations. 


LOW_GROUP 




1 Consumer group for low-priority sessions. 


ORAS DIAGNOSTICS 




Consumer group used bv database processes that create 
diagnostic dumps when critical errors occur 


0RASAUTOTASK_HEALTH_ 


_GROUP 


Reserved for future use. Included in 
ORAS AUTOTASK_HI GH_SUB_PLAN, 


0RASAUTOTA3K_MEDIUM_ 


_GR0UP 


Consumer group for medium-priority maintenance tasks. 


0RASAUTOTASK_SPACE_GROUP 


Consumer group for Automatic Segment Advisor maintenance 
task. Included in ORASAUTOTASK_HIGH_SUB_PLAN, 
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Table 25-2 (Cont.) Predefined Resource Consumer Groups 



Resource Consumer 


Group 


Description 


0RASADTOTASK_ 


-SQL. 


.GROUP 


Consumer group for Automatic SQL Tuning Advisor 
maintenance task. Included in 

ORAS AUTOTASK_HI GH_SUB_PLAN. 


0RASADTOTASK_ 


_STAT3_ 


GROUP 


Consumer group for optimizer statistics gathering m.aintenance 
task. Included in ORASAUTOTASK_HIGH_SUB_PLAH. 


0RASADTOTASK_ 


_URGEtJT 


_GROUP 


Consumer group for urgent maintenance tasks. 


OTHER_GROUPS 








Consumer group that applies collectively to all sessions that 
belong to a consumer group that is not part of the currently 

active plan, including sessions that belong to 
DEFAULT_COHSUMER_GROUP. 0THER_GROUPg must have a 
resource plan directive specified in every plan. It cannot be 
explicitly assigned to sessions through mapping rules. 


SYS_GROUP 








Consumer group for system administrators. It is the initial 
consumer group for all sessions created by user accounts SYS or 
SYSTEM. This initial consumer group can be overridden by 
session-to-consumer group mapping rules. 1 



DBMS_RESOURCE_MANAGER Package Procedures Summary 

Table 25-3 summarizes the procedures in the DBMS_RESOURCE_MANAGER package. 
You must have the ADMINISTER_RESOURCE_MANAGER privilege to run these 
procedures. 

Table 25-3 DBMS_RESOURCE_MANAGER Package Procedures 



Procedure 


Description 


CREATE_S IMPLE_PIJlH 


Creates a simple resource plan, containing up to eight consumer 
groups, in one step. This is the quickest way to get started with 
Oracle Database Resource Manager. 


CREATE_PLAM 


Creates a resource plan and specifies its allocation methods. 


UPDATE_PLAM 


Updates a resource plan. 


DELETE_PLAH 


Deletes a resource plan and its directives. 


DELETE_PLAN_CAS CADE 


Deletes a resource plan and all of its descendents. 


CREATE_COHSUMER_GROUP 


Creates a resource consumer group. 


UPDATE_CONSUMER_GROUP 


Updates a consumer group. 


DELETE_COHSUMER_GROUP 


Deletes a consumer group. 


CREATE_PLAM_DIRECTIVE 


Specifies the resource plan directives that allocate resources to 
resource consumer groups or subplans in a plan. 


UPDATE_PLAN_DIRECTIVE 


Updates plan directives 


DELETE_PLAH_DIRECT IVE 


Deletes plan directives 


CREATE_PENDING_AREA 


Creates a pending area (scratch area) within which changes can 
be made to a plan schema 


VALIDATE_PENDING_AREA 


Validates the pending changes to a plan schema 


CLEAR_PENI1ING_AREA 


Clears all pending changes from the pending area 


SUBMI T_PENDING_AREA 


Submits all changes for a plan schema 
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Table 25-3 (Cont.) DBMS_RESOURCE_MANAGER Padtage Procedures 



Procedure 


Description 


SET_IHITIAL_C0rJ3UMER_GR0UP 


Sets the initial consumer group for a user. This procedure has 
been deprecated. Oracle recommends that vou use the 
SET_COrJSUMER_GROUP_MAPPIHG procedure to specify the 
initial consumer group for a user or session. 


SWITCH_CONSUMER_GROUP_FOR_SESS 


Switches the consumer group of s specific session 


SWITCH_COHSUMER_GROUP_FOR_USER 


Switches the consumer group of all sessions belonging to a 
specific user 


SWITCH_PLAH 


Sets the current resource manager plan. 


SET_COHSaMER_GROUP_MaPPIHG 


Maps sessions to consumer groups 


SET_CONSUMER_GROUP_MAPP IfiG_PRI 


Establishes session attribute mapping priorities 



See Also: Oracle Database PL/SQL Packages and Types Reference for 
details on the DBMS_RESOURCE_MANAGER PL/SQL package. 

Resource Manager Data Dictionary Views 

Table 25— i lists views that are associated with the Resource M.inager, 
Table 25-4 Resource Manager Data Dictionary Views 



View 


Description 


DBA_RSRC_CONSDMER_GROUP_PRIVS 
TJSER_HSRC_COnSUMEE_GROUP_PRIVS 


DBA view lists all resource consumer groups and the users and 
roles to which they have been granted. USER view hsts all 
resource consumer groups granted to the user 


DBA_RSRC_CONSnMER_GR0UPS 


Lists all resource consumer groups that exist in the database. 


DBA_RSRC_MANAGER_SYSTEM_PRIVS 

USER_RSRC_MANAGER_SYSTEM_PRIVS 


DBA view lists all users and roles that have been granted 
Resource Manager system privileges. USER view lists all the 
users that are granted system privileges for the 

DBMg_RESOURCE_MAMAGER package. 


DBA_RSRC_PUlH_DIRECTIVES 


Lists all resource plan directives that exist in the database. 


DBa_RSRC_PLAHS 


Lists all resource plans that exist in the database. 


DBa_RSRC_GROUP_MaPPIHGS 


Lists all of the various mapping pairs for all of the session 

attributes. 


DBA_RSRC_MAPPIHG_PRI ORITY 


Lists the current mapping priority of each attribute. 


DB&_HIST_RSRC_PIAH 


Displays historical information about resource plan activation. 
This view contains AWR snapshots of 
VS R3RC_PLaH_HIST0RY. 


DBA_HIST_RSRC_CONS DMER_GROUP 


Displays historical statistical information about consumer 
groups. This view contains AWE. snapshots of 

VSRSRC_COH3_GR0UP_HISTORY. 


DBA_USERS 
USERS_USERS 


DBA view contains information about all users of the database. 
It contains the initial resource consumer group for each user. 
USER view contains information about the current user. It 
contains the current user's initial resource consumer group. 


VSACTIVE_SESS_P0OL_MTH 


Displays all available active session pool resource allocation 
methods. 


VSPiiRALLBL DEGREE LTMTT MTH 


Displays all available parallel degree limit resource allocation 
methods. 



Managing Resource Allocation witti Oracle Database Resource Manager 25-45 



Oracle Database Resource Manager Reference 



TaNe 25-4 (Cont.) Resource Manager Data Dictionary Views 



View 


Description 


VSQaEDEIKG_MTH 


Displiivs all available queuing resource allocation methods. 


Vg RSRC_COHS_GROUP_HISTORY 


For each entry in the view VSRSRC_PLAN_HISTORY, contains 
an entry for each consumer group in the plan showing the 
cumulative statistics for the consumer group. 


V$RSRC_COHSUMER_GROUP 


Displays information about active resource consumer groups. 
This view can be used for tuning. 


VS RSRC_COHSUMER_GROUP_CPU_MTH 


Displays all available CPU resource allocation methods for 
resource consumer groups. 


VSRSRCMGRMETRIC 


Displays a history of resources consumed and cumulative CPU 
wait time (due to resource management) per consumer group 
for the past minute. 


VSRSRCMGRMETRIC_HISTORY 


Displays a history of resources consumed and cumulative CPU 
wait time (due to resource management) per consumer group 
for the past hour on a minute-by-minute basis. If a new 
resource plan is enabled, the history is cleared. 


VSRSRC_PLAH 


Displays the names of all currently active resource plans. 


V5 RSRC_PLAH_CPU_MTH 


Displays all available CPU resource allocation methods for 
resource plans. 


VS RSRC_PLAM_HIS TORY 


Shows when Resource Manager plans were enabled or 
disabled on the instance. It helps you understand how 
resources were shared among the consumer groups over time. 


V5RSRC_SESSIOH_INF0 


Displays Resource Manager statistics for each session. Shows 
how the session has been affected by the Resource Manager 
Can be used for tuning. 


VSSE33IOH 


Lists session information for each current session. Specifically, 
lists the name of the resource consumer group of each current 

session. 



See Also: Oracle Database Reference for detailed information about 
the contents of each of these views 
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Oracle Scheduler Concepts 



In this chapter: 

■ Overview of Oracle Scheduler 

■ Basic Scheduler Concepts 

■ Advanced Scheduler Concepts 

■ Scheduler Architecture 



Note: This chapter discusses the use of the Oracle-sup phed 
DBMS_SCHEDULER package to administer the scheduling 
capabilities of Oracle Database, You can also use Oracle Enterprise 
Manager (EM) as an easy-to-use graphical interface for many of the 
same capabilities. 

See the Oracle Database PL/SQL Packages and Types Reference for 
DBMS_gCHEDULER syntax and the Oracle Enterprise Manager 
documentation set for more information, regarding Enterprise 
Manager, 



Overview of Oracle Scheduler 



To help vou simplif)' the scheduling of hundreds or even thousands of database tasks, 
Oracle provides a collection of functions and procedures in the DBMS_SCHEDULER 
PL /SQL package. Collectively, these functions are called Oracle Scheduler, and they 
are callable from any PL /SQL program, 

Oracle Scheduler (the Scheduler) enables database administrators and application 
developers to control when and where various tasks take place in the database 
environment. These tasks can be time consuming and complicated, so using the 
Scheduler can help you to improve the management and planning of these tasks. In 
addition, bv ensuring that manv routine database tasks occur without manual 
intervention, you can lower operating costs, implement more reliable routines, 
m.ininiize human error, and shorten the time windows needed. 

Some typical examples of using the Scheduler are: 

■ Database administrators can schedule and monitor recurring database 
maintenance jobs such as backups or nightiv data warehousing loads and extracts. 

■ Application developers can create programs and program libraries that end users 
can use to create or monitor their own jobs. In addition to tvpical database jobs, 
you can schedule and monitor jobs that run as part of an application suite. 
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What Can the Scheduler Do? 



The Scheduler provides complex enterprise scheduling functionality, which you can 
use to: 

■ Schedule job execution based on time or events 

The most basic capability of a job scheduler is the abUity to schedule a job to run at 
a particular date and time or when a particular event occurs. The Scheduler 
enables vou to reduce vour operating costs bv enabling you to schedule execution 
of jobs. For example, consider the situation where a patch needs to be applied to a 
database that is in production. To minimize disruptions, this task will need to be 
performed during non-peak hours. This can be easily accomplished using the 
Scheduler. Instead of having IT personnel manuallv carry out this task during 
non-peak hours, you can instead create a job and schedule it to run at a specified 
time using the Scheduler 

Scheduler jobs can be database jobs or external jobs. The tvpical Scheduler job is a 
database job (or just "job"), which runs PL /SQL code within the database. An 
external job runs an operating system executable such as a compiled C++ 
application or a shell script. External jobs can be run on the local host, or on a 
remote host with the help of a remote Scheduler agent. 

See "Creating Jobs" on page 27-2 for more information. 

■ Schedule job processing in a way that models your business requirements 

The Scheduler enables limited computing resources to be allocated appropriately 
among competing jobs, thus aligning job processing with your business needs. 
This is accomplished in the following ways: 

- Jobs that share common characteristics and behavior can be grouped into 
larger entities called job classes. You can prioritize among the classes by 
controlling the resources allocated to each class. This enables vou to ensure 
that your critical jobs have priority and have enough resources to complete. 
For example, if vou have a critical project to load a data warehouse, then vou 
can combine all the data warehousing jobs into one class and give prioritv to it 
over other jobs by aUocating it a high percentage of the available resources. 

- The Scheduler takes prioritization of jobs one step further, bv providing vou 
the abilit}' to change the prioritization based on a schedule. Because vour 
definition of a critical job can change over time, the Scheduler enables you to 
also change the priority' among vour jobs over that time frame. For example, 
you may consider the jobs to load a data warehouse to be critical jobs during 
non-peak hours but not during peak hours. In such a case, you can change the 
prioritv among the classes by changing the resource allocated to each class. 
See "Creating Job Classes" on page 27-22 and "Creating Windows" on 

page 27-23 for more information. 

- In addition to ruruiing jobs based on a time schedule, the Scheduler enables 
you to start jobs in response to system or business events. Your applications 
can detect events and then signal the Scheduler, Depending on the t\'pe of 
signal sent, the Scheduler starts a specific job. An example of using events to 
align vour job processing with business needs is to prepare event-based jobs 
for when a transaction fails, such as someone trying to withdraw more money 
from a bank account than is available. In this case, you could run jobs that 
check for suspicious activity in this account. 

■ Manage and monitor jobs 
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There are multiple states that a job undergoes from its creation to its completion. 
Scheduler activity is logged and information such as the status of the job and the 
last run time of the job can be easily tracked. This information is stored in views 
and can be easily queried using Enterprise Manager or a SQL query. These vievi's 
provide valuable information about jobs and their execution that can help vou 
schedule and manage vour jobs better For example, a DBA can easily track all jobs 
that failed for user scott. See "Monitoring and Managing the Scheduler" on 
page 28-7. 

Execute and manage jobs in a clustered environn\ent 

A cluster is a set of database instances that cooperates to perform the same task. 
Oracle Real Application Clusters (RAC) provides scalability and reliability 
without any change to your applications. The Scheduler fully supports execution 
of jobs in such a clustered environment To balance the load on your system and 
for better performance, vou can also specify the database service where you want 
a job to run. See "Using the Scheduler in Real Application Clusters Enviionments" 
on page 26-16 for more information. 
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The Scheduler offers a modular approach for managing tasks within the Oracle 
environment. Advantages of modularity include easier management of your database 
environment and reusability of scheduler objects when creating new tasks that are 
similar to existing tasks. 

In the Scheduler, most components aie database objects like a table, which enables you 
to use normal Oracle privileges. 

The basic elements of the Scheduler are: 

Programs 

Schedules 

Jobs 

Events 

Chains 



Programs 



See Also: "Advanced Scheduler Concepts" on page 26-8 



A Scheduler program object is a collection of metadata about what will be run by the 
Scheduler It includes information such as the name of the program object, program 
action (for example, a procedure or executable name), program type (for example, 
PL/SQL and Java stored procedures or PL/SQL anonymous blocks) and the number 
of arguments required for the program. 

A program is a separate entity from a job. Jobs run at a certain time or because a 
certain event occurred, and invoke a certain program. Jobs can be created that point to 
existing program objects, which means that different jobs can use the same program 
and run the program at different times and with different settings. Gi\en the right 
privileges, different users can thus use the same program without having to redefine 
it. This enables the creation of program libraries, where users can select from a list of 
existing programs. 
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BeciiiLse a Scheduler program, can invoke a stored procedure or other executable that 
requires arguments, a means is provided to store default values for those arguments as 
program attributes. 

See "Creating Programs" on page 27-12 for more information about programs, and 
"Jobs" on page 26-4 for an overview of jobs. 



Schedules 



Jobs 



A schedule specifies when and how manv times a job is executed. Jobs can be 
scheduled for processing at a later time or immediately. For jobs to be executed at a 
later time, the user can specify a date and time when the job should start. For jobs that 
repeat over a period of time, an end date and time can be specified, which indicates 
when the schedule expires. 

A schedule can also specify that a job be executed w^hen a certain event occurs, such as 
a badge swipe or inventory dropping below a threshold. For more information on 
events, see "Events" on page 26-6. 

Similar to programs, schedules are objects that can be named and saved in the 
database. Users can then share named schedules. For example, the end of a business 
quarter may be a common time frame for many jobs. Instead having to define an 
end- of- quarter schedule each time a new job is defined, job creators can point to a 
named schedule. 

Some examples of schedules you might use to control time-based jobs are: 

■ Run on Wednesdav, December 26th, 2001 at 2pm 

■ Run everv Mondav, at Sam, starting on December 26th, 2001, and ending on 
January 31st, 2002 

■ Run on every working day 

See "Creating Schedules" on page 27-16 for more information. 



A job is a user-defined task that is scheduled to run one or more times. It is a 
combination of what needs to be executed (the action) and when (the schedule). Users 
with the right privileges can create jobs either bv: 

■ Specif\'ing as job attributes both the action to perform (for example, an inline 
PL/SQL anonvmous block) and the schedule bv which to perform the action (for 
example, everv day at noon, or when a certain event occurs) 

■ Specif\'ing asjob attributes the names of an existing program object and an 
existing schedule object 

The Scheduler supports the following two job tvpes: 

■ Regular jobs 

■ Lightiveight jobs 

Regular Jobs 

Like programs and schedules, regular jobs are schema objects. In releases before 
Oracle Database 11^ Release 1, regular jobs were the only job type supported by the 
Scheduler, 

A regular job offers the maximum flexibility but does entail some overhead when it is 
created or dropped. Regular jobs can be created with a single procedure call. The user 
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h.is fine-grained control of the privileges on tlie job, and the job can have as its action a 
program or a stored procedure owned by another user. 

If a relatively small number of jobs that run infrequently need to be created, then 
regular jobs are preferred over lightweight jobs. 

Lightweight Jobs 

Lightiveight jobs are based on a job template from which privileges and (in some 
cases) job metadata is inherited. Use lightweight jobs when vou need to create and 
drop hundreds or thousands of jobs per second or when you have a library of 
programs that are available to be used as job templates. 

Lightweight jobs have the following characteristics: 

■ They are not schema objects hke regular jobs. 

■ They have a significant improvement in create and drop time over regular jobs 
because thev do not have the overhead of creating a schema object. 

■ Thev have a significantlv lower average session creation time than regular jobs. 

■ They have a small footprint on disk for job metadata and runtime data. 

You cannot set privileges on lightweight jobs because these jobs inherit privileges from 
the parent job template. Because the use of a job template is mandatory, it is not 
possible to create a fully self-contained lightiveight job. 

See Also: "Creating Jobs" on page 27-2 and "Examples of Using the 
Scheduler" on page 28-19 for examples of creating lightweight jobs 

Job Templates 

A job template is a database object that provides the necessary metadata needed for 
running a job (other than a schedule) and provides a privilege infrastructure that can 
be inherited bv any lightweight job. 

A job tenkplate is created based on a Scheduler program. 

Job Arguments 

You can specify job arguments to customize a named program object. Job arguments 
override the default argument values in the program object, and provide values for 
those program arguments that have no default value. In addition, job arguments can 
provide argument values to an inhne action {for example, a stored procedure) that the 
job specifies. 

A job cannot be enabled until all required program argument values are defined, 
either as defaults in a referenced program object, or as job arguments. 

A common example of a job is one that runs a set of nightly reports. If different 
departments require different reports, vou can create a program for this task that can 
be shared among different users from different departments. The program action 
would be to run a reports script, and the program would have one argument: the 
department number. Each user can then create a job that points to this program, and 
can specify the department number as a job argument. 

See "Creating Jobs" on page 27-2 for more information. 

Job instances 

A job instance represents a specific run of a job. Jobs that are scheduled to run only 
once w^ill have only one instance. Jobs that have a repeating schedule will have 
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multiple instances, witli each run of the job representing an instance. For example, a 
job that is scheduled to run on Tuesday, Oct. 8th 2002 will have one instance, A job 
that runs dailv at noon for a week has seven instances, one for each time the job runs. 

When a job is created, onlv one entr\' is added to the Scheduler's job table to represent 
the job. Each time the job runs, an entry is added to the job log. Therefore, if you create 
a job that has a repeating schedule, you will find one entry in the job views and 
multiple entries in the job log. Each job instance log entry provides information about 
a particular run, such as the job completion status and the start and end time. Each run 
of the job is assigned a unique log id which is used in both the job log and job run 
details views. 

See "Schedider Data Dictionary Views" on page 28-31 for more information. 



Events 



An event is a message sent bv one application or system process to another to indicate 
that some action or occurrence has been detected. An event is raised (sent) by one 
application or process, and consumed (received) by one or more applications or 
processes. 

There are two kinds of events in the Scheduler: 

■ Events raised by the Scheduler 

The Scheduler can raise an event to indicate state changes that occur within the 
Scheduler itself. For example, the Scheduler can raise an event when a job starts, 
when a job completes, when a job exceeds its allotted run time, and so on. The 
consumer of the event is an application that takes some action in response to the 
event. 

For example, if due to a high svstem load, a job is still not started 30 minutes after 
the scheduled start time, the Scheduler can raise an event that causes a handler 
application to send a notification e-mail to the database administrator, 

■ Events raised by an apphcation 

An application can raise an event to be consumed by the Scheduler The Scheduler 
reacts to the event by starting a job. You can create a schedule that references an 
event instead of containing date, time, and recurrence information. If a job is 
assigned to such a schedule (an evenl schedule), the job runs when the event is 
raised. You can also create a job that has no schedule assigned and that directly 
references an event as the means to start the job. 

For example, when an inventory tracking system notices that the inventory has 
gone below a certain threshold, it can raise an event that starts an inventory 
replenishment job. 

The Scheduler uses Oracle Streams Advanced Queuing to raise and consume events. 
When raising a job state change event, the Scheduler enqueues a message onto a 
default event queue. Applications subscribe to this queue, dequeue event messages, 
and take appropriate action. When raising an event to notifj' the Scheduler to start a 
job, an application enqueues a message onto a queue that was specified when setting 
up the job. 

See Also: 

■ Oracle Streams Advanced Qiietiiiig User's Guide for more 
information on Advanced Queuing 

■ "Using Events" on page 27-33 for more information on Events 
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Chains 

A chain is a grouping of programs that are linked together for a single, combined 
objective. An example of a chain might be "run program A and then program B, but 
onlv run program C if programs A and B complete successfully, otherwise run 
program D. " A Scheduler job can point to a chain instead of pointing to a single 
program object. 

Each position within a chain of interdependent programs is referred to as a step, 
Tvpically, after an initial set of chain steps has started, the execution of successive 
steps depends on the completion of one or more previous steps. Each step can point to 
one of the following: 

■ A program 

■ Another chain {a nested chain) 

■ An event 

A step that points to an event waits until the specified event is raised. If the event 
occurs, the step completes successfully. 

Multiple steps in the chain can invoke the same program or nested chain. 

In a sense, a chain resembles a decision tree, with many possible paths for selecting 
which steps run and when.. A list of rules is used to decide which actions to perform at 
any particular stage. An example of a rule is "If step 2 fails or step 3 fails, wait an hour 
and then start step 4." 

While a job pointing to a chain is running, the current state of all steps of the running 
chain can be monitored. 

A typical situation w^here you might want to create a chain is to combine the different 
programs necessarv for a successful financial transaction. 

See "Using Chains" on page 27^0 for more information. 

How Programs, Jobs, and Schedules are Related 

To define what is executed and when, you assign relationships among programs, jobs, 
and schedules. Figure 26-1 illustrates examples of such relationships. 

Figure 26-1 Relationships Among Programs, Jobs, and Scliedules 




P8 



P9 



P10 



J20 



/^ 



J21 



J22 



\./ 



J23 



J 24 



53 



S4 



Oracle Scheduler Concepts 26-7 



Advanced Scheduler Concepts 



To understand Figure 26-1, consider a situation where tables are being analyzed. In 
this example, PI would be a program to analvze a table using the DBMS_STATS 
package. The program has an input parameter for the table name. Two jobs, Jl and 
J2, both point to the same program, but each supplies a different table name, 
Additionallv, schedule SI could specify a run time of 2:00 a.m. everv day. The end 
result would be that the two tables named in Jl and J2 are tinalyzed daily at 2:00 a.m. 

Note that J4 points to no other entit}', so it is self-contained with all relevant 
information defined in the job itself. P2, P9 and S2 illustrate that you can leaye a 
program or schedule unassigned if you want. You could, for example, create a 
program that calculates a year-end inventory and temporarily leave it unassigned to 
any job. 
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Job Classes 



Many Scheduler capabilities enable database administrators to control more advanced 
aspects of scheduling. Typically, these topics are not as important for application 
developers. 

This section discusses the following iidvanced topics: 

■ Job Classes 

■ Windows 

■ Window Groups 

■ External Jobs 

■ Scheduler Support for Oracle Data Guard 



Job classes provide a wav to: 

■ Assign the same set of attribute values to member jobs 

Each job class specifies a set of attributes, such as logging level. When you assign a 
job to a job class, the job inherits those attributes. For example, you can specify the 
same policy for purging log entries for all payroll jobs. 

■ Set ser\'ice affinity for member jobs 

You can set the service attribute of a job class to a desired database ser\'ice 
name. This determines the instances in a Real Application Clusters environment 
that run the member jobs, and optionally the system resources that are assigned to 
member jobs. See "Service Affinity when Using the Scheduler" on page 26-16 for 
more information. 

■ Set resource allocation for member jobs 

Job classes provide the link between the Database Resource Manager and the 
Scheduler, because each job class can specif}' a resource consumer group as an 
attribute. Member jobs then belong to the specified consumer group, and are 
assigned resources according to settings in the current resource plan. 

Alternatively, vou can leave the i:esoui:ce_consum.ei:_group attribute NULL 
and set the service attribute of a job class to a desired database sen'ice name. 
That service can in turn be mapped to a resource consumer group. If both the 
resource_consumer_gr oup and service attributes are set, and the 
designated service maps to a resource consumer group, the resource consumer 
group named in the resource_consuiner_group attribute takes precedence. 
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See Chapter 25, "M.inaging Resource Allocation with Or.icle Datahiise Resource 
Manager" for more information on miipping services to consumer groups. 

Group jobs for prioritization 

Within the same job class, vou can assign priority values of 1-5 to individual jobs 
so that if two jobs in the class are scheduled to start at the same time, the one with 
the higher prioritv takes precedence. This ensures that vou do not have a less 
important job preventing the timely completion of a more important one. 

If two jobs have the same assigned prioritv value, the job with the earlier start date 
takes precedence. If no priorit}" is assigned to a job, its priorit\' defaults to 3. 

Note: Job priorities are used only to prioritize among jobs in the 
same class. 

There is no guarantee that a high priority job in class A will be 
started before a low prioritj' job in class B, even if thev share the 
same schedule. Prioritizing among jobs of different classes depends 
on the current resource plan and on the designated resource 
consumer group or service name of each job class. 



When defining job classes, you should trv to classify jobs by functionalitv. Consider 
dividing jobs into groups that access similar data, such as marketing, production, 
sales, finance, and human resources. 

Some of the restrictions to keep in mind are: 

■ A job must be part of exactly one class. When vou create a job, vou can specif;' 
which class the job is part of. If vou do not specify a class, the job automatically 

becomes part of the class DEFAULT_JOB_CLASS. 

■ Dropping a class while there are still jobs in that class results in an error You can 
force a class to be dropped even if there are still jobs that are members of that 
class, but all jobs referring to that class are then automatically disabled and 
assigned to the class DEFAULT_JOB_CLASS. Jobs belonging to the dropped class 
that are already running continue to run under class settings determined at the 
start of the job. 



Windows 



You create windows to automaticallv start jobs or to change resource allocation among 
jobs during various time periods of the dav, week, and so on. A window is 
represented bv an interval of time with a well-defined beginning and end, such as 
"from 12am-6am", 

Windows work with job classes to control resource allocation. Each window specifies 
the resource plan to activate when the window opens (becomes active), and each job 
class specifies a resource consumer group or specifies a database service, which can 
map to a consumer group. A job that runs within a window therefore has resources 
allocated to it according to the consumer group of its job class and the resource plan of 
the window. 

Figure 26-2 shows a workdav that includes two windows. In this configuration, jobs 
that belong to the job class that links to Consumer Group 1 get more resources in the 
morning than in the afternoon. The opposite is true for jobs in the job class that links to 

Consumer Group 2. 
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Figure 26-2 Windows help define the resources that are allocated to jobs 
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See Chapter 25, "Managing Resource Allocation witli Oracle Database Resource 
Manager" for more iniormation on resource plans and consumer groups. 

You can assign a priority to each window. If window^s overlap, the window with the 
highest priorit\' is chosen over other windows with lower priorities. The Scheduler 
automatically opens and closes windows as window start times and end times come 
and go. 

A job can name a window in its Hchedule_name attribute. The Scheduler then starts 
the job when the window opens. If a window is already open, and a new job is created 
that points to that window, the job is not started until the next lime the window opens. 

See "Creating Windows ' on page 27-23 for examples of creating and using windows. 



Note: If necessary, you can temporarily block windows from 
switching the current resource plan. For more information, see 
"Enabling Oracle Database Resource Manager and Switching Plans" 
on page 25-30, or the discussion of the 

DBMS_RESOURCE_MAWAGER . SWITCH_PLAW package procedure in 
Oracle Database PL/SQL Packages and Types Reference. 



Window Groups 



You can group windows for ease of use in scheduling jobs. If a job must run during 
multiple time periods throughout the day, week, and so on, vou can create a window 
for each time period, and then add the windows to a window group. You can then set 
the schedule_name attribute of the job to the name of this window group, and the 
job executes during all the time periods specified in the window group. 

For example, if vou had a window called "Weekends" and a window called 
"Weeknights," vou could add these two windows to a window group called 
"Downtime." The data warehousing staff could then create a job to run queries 
according to this Downtime window group — on weeknights and weekends — when 
the queries could be assigned a high percentage of available resources. 

If a window in a window group is alreadv open, and a new job is created that points to 
that window group, the job is not started until the next window in the window group 
opens. 

See "Creating Window Groups" on page 27-30 for examples of creating window 
groups. 
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External Jobs 



This section discusses the Scheduler's support for external jobs. 

An external job is an operating system executable that runs outside the database. For 
an external job, job_tYpe is specified ns EXECUTABLE. (If using named programs, the 
corresponding program_type would be EXECUTABLE.) The job_action (or 
corresponding program_action if using named programs) is the full operating 
svstem-dependent path of the desired external executable, excluding any command 
line arguments. An example might be /usr/ local /bin/perl or 
C : \perl\bin\perl. The program or job arguments for Wpe EXECUTABLE must be a 
string type such as CHAR orVARCHAR2. They are set with the 

DBMS_ SCHEDULER . SET_JOB_ARGUMENT_VALUE procedure. 

Most, but not all, platforms support external jobs. For platforms that do not support 
external jobs, creating or setting the attribute of a job or a program to Wpe 
EXECUTABLE returns an error See vour operating svstem-specific documentation for 
more information. Note that a Windows batch file is not directly executable and must 
be run with cmd . exe. 

Like any Scheduler job, you can assign a schema when vou create the job. That schema 
then becomes the job owner Note that although it is possible to create an external job 
in the SYS schema, Oracle recommends against this practice. 

The CREATE JOB and CREATE EXTERNAL JOB privUeges are both required for any 
schema that runs externaljobs. 

External jobs must run on the host computer as some operating svstem user Thus, vou 
must be able to assign operating system credentials to any external job that you create. 
You do so with a database object introduced in Oracle Database llg Release 1 called a 
credential. 

There are two tvpes of external jobs: local externaljobs and remote externaljobs. Local 
external jobs run on the same computer as the database that schedules them. Remote 
external jobs run on a remote host — that is, on a host computer other than the 
computer running the database that schedules them. 

Credentials, local external jobs, and remote externaljobs are discussed in detail in the 
followingsections: 

■ About Credentials 

■ About Local Externaljobs 

■ About Remote Externaljobs 

About Credentials 

A credential is a username and password pair stored in a dedicated database object. 
You set the credent ial_name attribute of an external job to designate a credential 
for that job. The job then runs under the username and password specified bv that 
credential. 

You use the DBMS_SCHEDULER . CREATE_CREDEWTIAL procedure to create a 
credential, A credential can be used onlv by a job whose owner has EXECUTE 
privileges on the credential or whose owner is also the owner of the credential. 
Because a credential belongs to a schema like any other schema object, you use the 
GRANT SQL statement to grant privileges on a credential. 

BEGIH 

DBMS_SCHEDDLER.CREaTE_CREDENTIAL('HRCREDENTIAL', 'HR' , 'hrOOlSlS') ; 
EKD; 
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GRANT EXECUTE OH SYSTEM . HRCEEDENT I AL to HRJOBDSER; 

You can query the '_SCHEDULER_CREDENTIALS views to see a list of credentials in 
the database. Credential passwords are stored obfuscated, and are not displayed in the 

* SCHEDULER CREDENTIALS views. 



About Local External Jobs 

A local external job runs on the same computer as the Oracle database that schedules 
it. For such a job, the destination job attribute is null or contains a value of 
localhost. You do not have to assign a credential to a local external job, although 
Oracle recommends that you do so. If vou do not assign a credential bv setting the 
credential_nai[ie job attribute, the job runs under default credentials. Table 26-1 
defines the default credentials for different platforms and different job owners. 

Table 26-1 Default Credentials for Remote External Jobs 

Job in SYS 

Schema? Platform Default Credentials 



Yes 



Nq 



All 



User who installed Oracle Database 



No UNIX and Linux Values of the run-user and run-group attributes 

specified in the 
OiW CLE_HOM£/rdbmE/admin/externaljob,ora file 



Windows 



User that the OracleJobScheduler Wfindow^s 
service runs as 



Note: Default credentials mav be deprecated in a future release. It is 
therefore best to assign a credential to every local external job. 



To disable the running of local external jobs that were not assigned credentials, 
remove the run_user attribute from the 

OR;5CLB_ifOMB/rdbms/admin/external job.ora file (UNIX and Linux) or stop the 
OracleJobScheduler service (Windows). Note that these steps do not disable the 
running of local external jobs in the SYS schema. 

Some additional post-installation steps might be required to ensure that local external 
jobs are enabled. See your operating system-specific documentation for anv 
post-installation configuration steps. For example, on Windows, you must set the 
username and password for the user account under which the 
OracleJobScheduler service is to run, and then enable the service. 

About Remote External Jobs 

A remote external job runs on a host computer other than the computer running the 
Oracle database that schedules it. For purposes of this discussion, the database host is 
the computer containing the database used to schedule a remote external job, and the 
remole host is the computer that the remote external job is to run on. The remote host 
mav or mav not have Oracle Database installed. However, in all cases, the remote host 
has a Scheduler agent that the database communicates with to start external jobs on the 
remote host. The agent is also involved in returning execution results to the database. 
The agent is an executable on a remote host that is installed separatelv. It listens on a 
network port for incoming job requests and executes them. 
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When setting up to mn a remote external job. you specify a remote liost and port as 
the destination attribute of the job. In addition, you must specify a credential for a 
remote external job. 

See Also: 

■ "Creating Rem.ote External Jobs" on page 27-6 

■ "Enabling and Disabhng Remote External Jobs" on page 28-13 

Scheduler Support for Oracle Data Guard 

Beginning with Oracle Database 11;^ Release 1, the Scheduler can run jobs based on 
whether a database is a primar}" database or a logical standby in an Oracle Data Guard 
environment. 

For a physical standby database, anv changes made to Scheduler objects or any 
database changes made by Scheduler jobs on the primary database are applied to the 
physical standby like any other database changes. For the primary' database and 
logical standby databases, there is additional functionalit}' that enables you to specify 
that a job can run only when the database is in the role of the primary database, or can 
run only when the database is in a logical standby role. 

You do this using the DBMS_SCHEDULER . SET_ATTRIBUTE procedure to set the 
database_role job attribute to one of ti\'o values: PRIMARY or LOGICAL STANDBY, 
(To run a job in both roles, vou can make a copy of the job and set databa3e_role to 
PRIMARY for onejob and to LOGICAL STANDBY for the other). 

On switchover or failover, the Scheduler automatically switches to rurmingjobs 
specific to the new role. DML is replicated to the job event log so that on failover, a 
record of what had run successfully on the primary database until it failed is available. 

See Also: 

■ "Examples of Setting Attributes" on page 28-24 for an example of 
setting the databaEe_role attribute 

■ "Example of Creating a |ob In an Oracle Data Guard 
Environment" on page 28-29 

■ Orade Data Guard Concepts imd Atlniinislriitioti 

Scheduler Architecture 

This section discusses the Scheduler's architecture, and describes: 

The Job Table 

The Job Coordinator 

How Jobs Execute 

Job Slaves 

Using the Scheduler in Real Application Clusters Environments 
Figure 26-3 illustrates how jobs are handled by the database. 



Oracle Sctieduler Concepts 26-13 



Scheduler Architecture 



Figure 26-3 Scheduler Components 

Client 




Job Slaves 



The Job Table 



The job table is a container for ail the jobs, with one table per database. The job table 
stores information for all jobs such as the owner name or the level of logging. You can 
find this information in the ■'_SCHEDULER_JOBS views. 

Jobs are database objects, and can therefore accumulate and take up too much space. 
To avoid this, job objects are automaticallv dropped bv default after completion. This 
behavior is controlled by the auto_drop job attribute. 

See "Scheduler Data Dictionary Views" on page 28-31 for the available job views and 
administration. 



The Job Coordinator 



The job coordinator background process (c jqNNN) is automaticallv started and 
stopped on an as-needed basis. At database startup, the job coordinator is not started, 
but the database does monitor whether there are any jobs to be executed, or windows 
to be opened in the near future. If so, it starts the coordinator. 

As long as theie are jobs or windows rurming, the coordinator continues to run. After 
there has been a certain period of Scheduler inactivity and there are no jobs or 
windows scheduled in the near future, the coordinator is automatically stopped. 

When the database determines whether or not to start the job coordinator, it takes the 
service affinitv of jobs into account. For example, if there is only one job scheduled in 
the near future and the job class to which this job belongs has ser\'ice affinitv for only 
two out of the four RAC instances, only the job coordinators for those two instances 
aie started. See "Service Affinity when Using the Scheduler" on page 26-16 for more 
information. 

The job coordinator: 

■ Controls and spawns the job slaves 

■ Queries the job table 

■ Picks up jobs from the job table on a regular basis and places them in a memory 
cache. This improves performance bv avoiding going to the disk 

■ Takes jobs from the memory cache and passes them to job slaves for execution 
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■ Cleans up the job slave pool when sla\es are no longer needed 

■ Goes to sleep when no jobs are scheduled 

■ Wakes up when a new job is about to be executed or a job was created using the 
CREATE_JOB procedure 

■ Upon database startup after an abnormal database shutdown, recovers anv jobs 
that were running. 

You do not need to set when the job coordinator checks the job table; the system 
chooses the time frame automaticallv. The coordinator automaticallv determines how 
many job slaves to start based on CPU load and the number of outstanding jobs. In 
special scenarios, you can limit the maximum number of slaves to be started bv the 
coordinator by setting the Max_JOB_SLAVE_PROCESSES parameter with the 

DBMS_SCHEDULEE . SET_SCHEDULER_ATTRIBUTE procedure. 

One job coordinator is used per instance. This is also the case in RAC environments. 

See Also: "Scheduler Data Dictionary Views" on page 28-31 for 
job coordinator administration and "Using the Scheduler in Real 
Application Clusters Environments ' on page 26-16 for RAC 
information 

How Jobs Execute 

When a job is picked for processing, the job slave: 

1. Gathers all the metadata needed to run the job. As an example, arguments of the 
program and privilege information. 

2. Starts a database session as the owner of the job, starts a transaction, and then 
starts executing the job. 

3. Once the job is complete, the slave commits and ends the transaction. 

4. Closes the session. 



Job Slaves 



Job slaves actually execute the jobs you submit. Thev are awakened bv the job 
coordinator when it is time for a job to be executed. Thev gather metadata to run the 
job from thejob table. 

When a job is done, the slaves: 

Reschedule the job If required 

Update the state in the job table to reflect whether the job has completed or is 
scheduled to run again 

Insert an entr\' into the job log table 

Update the run count, and if necessary, failure count and retrv count 

Clean up 

Look for new work (if none, they go to sleep) 

The Scheduler dynamically sizes the slave pool as required. 
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Using the Scheduler in Real Application Clusters Environments 

In a Real Application Clusters (RAC) environment, the Scheduler uses one job table for 
each database and one job coordinator for each instance. The job coordinators 
communicate with each other to keep information current. The Scheduler attempts to 
balance the load of the jobs of a job class across all available instances vi'hen the job 
class has no service affinity, or across the instances assigned to a particular service 
when the job class does have service affiniK", 

Figure 26^ illustrates a tj'pical RAC architecture, with each instance's job coordinator 
exchanging information with the others. 



Figure 26-4 RAC Architecture and the Scheduler 
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Service Affinity wlien Using tlie Scheduler 

The Scheduler enables vou to specify the database service under which a job should he 
run (service affinity). This ensures better availabilit\' than instance affinity because it 
guarantees that other nodes can be dvnamically assigned to the ser\'ice if an instance 
goes down. Instance affinit\' does not have this capability, so. when an instance goes 
down, none of the jobs with an affinit\' to that instance will be able to run until the 
instance comes back up. Figure 26-5 illustrates a typical example of how services and 
instances could be used. 
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Figure 26-5 Service Affinity and the Scheduler 
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In Figure 26—5, vou could change the properties of the services and the Scheduler v/iU 
automatically recognize the change. 

Each job class can specify a database service. If a sen'ice is not specified, the job class 
belongs to an internal service that is guaranteed to be mapped to ever}' running 
instance. 
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Scheduling Jobs with Oracle Scheduler 



In this chapter: 

Scheduler Objects and Their Naming 

Using Jobs 

Using Programs 

Using Schedules 

Using Job Classes 

Using Windows 

Using Window Groups 

Using Events 

Using Chains 

Allocating Resources Among Jobs 

Note: This chapter describes how to use the DBMS_SCHEDULER 
package to work with Scheduler components. You can accomplish the 
same tasks using Oracle Enterprise Manager. 



Scheduler Objects and Their Naming 

Each Scheduler object is a complete database schema object of the form 
[schema . ] name. Scheduler objects exactly follow the naming rules for database 
objects and share the SQL namespace with other database objects. 

When names for Scheduler objects are used in the DBMS_SCHEDULER package, SQL 
naming rules continue to be followed. Bv default, Scheduler object names are 
uppercase unless they are surrounded bv double quotes. For example, when creating a 
job,job_name => ' mY_ j ob ' is the same as job_naine => 'My_Job' and 
job_naine => ' MY_JOB ' , but not the same as job_name => ' "mY_job" '.These 
naming rules are also followed in those cases where com ma- delimited lists of 
Scheduler object names are used within the DBMS_SCHEDULER package. 



Using Jobs 



See Oracle Database SQL Language Reference for details regarding naming objects. 



A job is the combination of a schedule and a program, along with any additional 
arguments required by the program. This section introduces vou to basic job tasks, 
and discusses the following topics: 
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Job Tasks and Their Procedures 

Creating Jobs 

Copying Jobs 

Altering Jobs 

Running Jobs 

Stopping Jobs 

Dropping Jobs 

Disabling Jobs 

Enabling Jobs 

See Also: "Jobs" on page 26A for an overvievi' of jobs. 



Job Tasks and Their Procedures 



Table 27-1 illustrates common job tasks and their appropriate procedures and 
privileges: 

Table 27-1 Job Tasks and Their Procedures 



Task 



Create a job 
Alter a job 

Run a job 
Copy a job 
Drop a job 
Stop a job 
Disable a job 
Enable a jab 



Procedure 



Privilege Needed 



CREATE_JOB or 
CREATE_JOBS 

3ET_ATTRIBUTE or 

SET_JOB_ATTRIBUT 

ES 

RUH_JOB 

C0PY_JOB 

DROP_JOB 

STOP_JOB 

DISABLE 

ENABLE 



CREATE JOB or CREATE AHY JOB 

ALTER or CREATE AHY JOB or be the owner 

ALTER or CREATE AHY JOB or be the owner 
ALTER or CREATE AHY JOB or be the owner 
ALTER or CREATE AHY JOB or be the owner 
ALTER or CREATE AHY JOB or be the owner 
ALTER or CREATE AHY JOB or be the owner 
ALTER or CREATE AHY JOB or be the owner 



See "Scheduler Privileges" on page 28-30 for further information regarding privileges. 



Creating Jobs 



You create one or more jobs using the CREATE_JOB or CREATE_JOBS procedures or 
Enterprise M.inager, The CREATE_JOB procedure is used to create a single job. This 
procedure is overloaded to en.ible you to create different t\"pes of jobs that are based 
on different objects. Multiple jobs can be created using the CREATE_JOBS procedure. 

For each job being created, vou specifv a job tv'pe, an action, a schedule, and other 
attributes. The job t\'pe specifies whether to create a regular job or a lightweight job. If 
you do specify a job tvpe, the default t\'pe is regular 

For example, the following statement creates a single job called update_sales, 
which calls a stored procedure in the OPS schema that updates a sales summary table: 



BEGIH 

DBMS_SCHEDtJLER . CHEATE_JOB 
j ob_nanie => 



' update_sales ' , 
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j ob_type 


=> 


job_action 


=> 


start_date 


=> 


repeat_interval 


=> 


end date 


=> 


j ob_class 


=> 


conments 


=> 


END; 




/ 





STORED_PEOCEDURE', 

0PS.SALES_PKG.UPDATE_SALES_3UMMARY' , 
28-APR-03 07.00.00 PM Australia/Sydney', 
FREQ=DAILYrIMTEKVAL=2 ', /' every other day */ 
20-NOV-04 07.00.00 PM Australia/Sydney', 
batch_update_jobs ' , 
My new j ob ' ) ; 



You can create a job in another schema by specifying schema . job_name. The creator 
of a job is, therefore, not necessarily the job owner. The job owner is the user in whose 
schema the job is created, while the job creator is the user who is creating the job. Jobs 
are executed with the privileges of the schema in which the job is created. The NLS 
environment of the job when it runs is that which was present at the time the job was 
created. 

After a job is created, it can be queried using the *_SCHEDULER_JOBS views. Jobs are 
created disabled bv default and need to be enabled to run. 

Jobs are set to be automatically dropped by default after they complete. Setting the 
auto_drop attribute to FALSE causes the job to persist. Note that repeating jobs are 
not auto-dropped unless the job end date passes, the maximum number of runs 
(max_runs) is reached, or the maximum number of failures is reached 
(max_f allures). 

Setting Job Attributes 

You can set job attributes when creating the job, or you can set them after the job is 
created by using the SET_ATTRIBUTE or SET_JOB_ATTRIBUTES procedures or 
Enterprise Manager (Some job attributes can be set only after the job is created.) 

When you set the COMMIT_SEMANTICS parameter of a job to TRANSACTIONAL or 
ABSORB_ERRORS, you can perform multiple operations within the scope of a single 
transaction. 

See Oracle Database PL/SQL Packages and Types Reference for information about the 
SET_ATTRIBUTE and SET_JOB_ATTRIBUTES procedures and about the various job 
attributes. 

Setting Job Arguments 

After creating a job, you may need to set job arguments if; 

■ The inline job action is a stored procedure or other executable that requires 
arguments 

■ The job references a named program object and you want to override one or more 
default program arguments 

■ Thejob references a named program object and one or more of the program 
arguments were not assigned a default value 

To set job arguments, use the SET_JOB_ARGUMENT_VALUE or 
SET_JOB_ANYDATA_VALUE procedures or Enterprise Manager. 

SET_JOB_ANYDATA_VALUE is used for complex data types that must be encapsulated 
in an ANYDATA object. 
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Note: 



The 3ET_J0B_ARGUMENT_VALUE procedure can be used to set 
arguments of lightweight jobs but only if the arguments are of 

type VARCHAR2. 



An example of a job that might need arguments is one that starts a reporting program 
that requires a start date and end date. The following code example sets the end date 
job argument, which is the second argument expected by the reporting program: 

BEGIH 
DBMS_SCHEDt;LER.SET_JOB_flRGDMENT_VALBE { 

]ol;_nanie => ' ops_reports ' , 

argumentjiosition => 2, 

argument_value => ' 12-DEC-03 ' ) ; 

END; 
/ 

If you use this procedure on an argument whose value has already been set, it will be 
overwritten. You can set argument values using either the argument name or the 
argument position. To use argument name, the job must reference a named program 
object, and the argument must have been assigned a name in the program object If a 
program is inlined, only setting by position is supported. Arguments are not 
supported for jobs of tvpe plsql_block. 

To remove a value that has been set, use the RESET_JOB_ARGUMENT procedure. This 
procedure can be used for both regular and ANYDATA arguments. 

See Oracle Database PL/SQL Packages and Types Reference for information about the 

SET_JOB_ARGUMENT_VALUE and SET_JOB_ANYDATA_VALUE procedures. 

Ways of Creating Jobs 

Because the GREAT E_ JOB procedure is overloaded, there are several different ways of 
using it In addition to inlining a job during the job creation, vou can also create a job 
that points to a named program and schedule. This is discussed in the foUow^ing 
sections; 

■ Creating Jobs Using a Named Program 

■ Creating Jobs Using a Named Schedule 

■ Creating Jobs Using a Named Program and Schedule 

Creating Jobs Using a Named Program You can create a job by pointing to a named 
program instead of inlining its action. To create a job using a named program, vou 
specify the value for prograni_name in the GREAT E_ JOB procedure when creating 
the job and do not specify the values for job_tYpe, job_action, and 
nuniber_of _arg"UTiients, 

To use an existing program when creating a job, the owner of the job must be the 
owner of the program or have EXEGUTE privileges on it. An example of using the 
GREATE_JOB procedure with a named program is the following statement, which 
creates a regular job called mY_new_ j obi: 

BEGIH 
DBMS_3CHEDiri£R.CREATE_J0B ( 

j ob_name = > ' my_new_ j obi ' , 

prograirL_naine => ' my_Eaved_prograiii ' , 

repeat_interval => 'FREQ=DAILY;BYH0UE=12 ' . 



27-4 Oracle Database Administrator's Guide 



Using Jobs 



comments 

EUD; 
/ 



=> 'Daily at noon'); 



The following statement creates a lightweight job that uses the program MY_PROG as a 
job template. 



BEGIN 

DBMS SCHEDULER. CREATE JOB 



j ob_name 


=> 


pr ogr am_name 


=> 


repeat_interval 


=> 


end time 


=> 


j ob_style 


=> 


conments 


=> 


END; 





'my_lightweight__jobl ' , 

■MY_PROG', 

■FREQ=DAIL¥;B¥_H0UE=9 ' , 

■30-APR-07 04.00.00 AM Australia/Sydney', 
'LIGHTOEIGHT' , 
'New lightweight job based on a program'); 



/ 



Creating Jobs Using a Named Schedule You can also create a job by pointing to a named 
schedule instead of inlining its schedule. To create a job using a named schedule, you 
specify the value for schedule_name in the GREAT E_ JOB procedure when creating 
the job and do not specify the values for s tart_date, repeat_interval, and 
end_date. 

You can use any named schedule to create a job because all schedules are created with 
access to PUBLIC, An example of using the CREATE_JOB procedure with a named 
schedule is the following statement, which creates a regular job called niY_new_job2: 



BEGIN 










DBMS_SCHEDULER . CREATE. 


_JOB 


( 






j ob_naine 




=> 


'ii^_new_job2 ' , 




j ob_type 




=> 


'PLSQL_BLOCK', 




job_action 




=> 


'BEGIN SAI£S PKG. UPDATE SAT,F<; SUMMARY; 


END; 


E chedu 1 e_nanie 




=> 


'ii^_saved_sched"ule' ) ; 




END; 











/ 

Creating Jobs Using a Named Program and Scliedule A job can also be created by pointing 
to both a named program and schedule. An example of using the CREATE_JOB 
procedure with a named program and schedule is the following statement, which 
creates a regular job called mY_new_ j ob3 based on the existing program 

mY_saved_pr ogr ami and the existing schedule my_Eaved_schedulel: 



BEGIN 

DBMS_SCHEDULER . CREATE_JOB 
j ob_name => 

program_naine => 

sched"ule_narne => 

END; 

/ 



' my_new_j ob3 ' , 
'my_saved_prograiiLl ' , 
' my_saved_sched"ulel ' 



The following statement creates a lightiv eight job that is based on the existing program 
MY_PROG and the existing schedule MY_SCHED, 



BEGIN 






DBMS_SCHEDULER . CREATE. 


_JOB 


( 


j ob_name 


=> 


'my_lightweight_]ob2 ' , 


pr ogr am_nairLe 


=> 


'my_prog' , 


s chedu 1 e_naiiie 


=> 


' my_sched ' , 


j ob_style 


=> 


'LIGHTWEIGHT'); 


END; 
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Creating Remote External Jobs 

The CREATE JOB and CREATE EXTERNAL JOB privileges are both required for any 
schema that creates remote external jobs. 

To create a remote external job: 

1. Create the job using the CREATE_JOB procedure. 

2. Create a credential using the CREATE_CREDENTIAL procedure of the 

DBMS_ SCHEDULER package. 

The following example creates a credential named NICKID, which consists of the 
username NICK and the password f iresign: 

SQL> EXEC DBMS_SCHEa)ULER.CREATE_CREDENTIALCHICKID' , 'MICK', 'firesign'); 

3. Set the credent ial_name attribute of the job using the SET_ATTRIBUTE 
procedure. 

The job owner must have EXECUTE privileges on the credential or be the owner of 
the credential. 

4. Set the destination attribute of the job using the SET_ATTRIBUTE procedure. 

The attribute must be of the form hostport, where hosl is the host name or IP 
address of the remote host, and port is the port on vi'hich the Scheduler agent on 
that host listens. To determine this port number, view the file schagent . conf, 
which is located in the Scheduler agent home directory on the remote host, 

5. Enable the job using the ENABLE_JOB procedure. 

Example 1 

The following example creates a remote external job named CLEANLOGS that uses a 
credential named LOGOWNER. The destination host and port number are app4 5 5 and 

12345, 

BEGIN 
DBMS_SCHEDULER.CREATE_JOB[ 

jol)_name => 'CLEAFL0G3', 

jol>_type => 'EXECUTABLE', 

jol>_action => ' /home/logowner/cleanlogs ' , 

repeat_interval => ' FREQ=DAILY; BYHOUR=23', 

enabled => FALSE) ; 

DBMS_3CHEDULER .SET_ATTRIBUTE { ' CLEMLOGS ' , ' crederitial_iiame ' , ' LOGOWNER ' ) ; 
DBMS_3CHEDULER.SET_ATTRIBUTE{ 'CLEANLOGS', 'destination', ' app455 : 12345 ' ) ; 
DBMS_3CHEDULER. ENABLE ( ' CLEANLOGS ' ) ; 
END; 
/ 

Example 2 

The following example creates the same remote external job for multiple remote hosts. 
The PL/SQL code includes a loop that iterates over the host names, remote_cred is 
the name of a credential that is valid on all hosts. The list of destinations is a list of host 
names and Scheduler agent ports. The executable being run on all hosts is the 
application /u01/app/ext_backup, 

declare 

job__prefix varchar2 (30) := 'reinote_'; 

job_naiiie varchar2 (30) ; 

destinations dbms_utility .lnaiiie_arraY; 

begin 
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destinations (1) 
destinations [ 2 ) 
destinations ( 3) 
destinations (4) 



= 'hostl:1234' 

= 'host2:1234' 

= 'host3:1234' 

= 'host4:1234' 



for i in 1 . .destinations.LAST loop 

job_name := dbms_scheduler .generate_job_naine [ job_prefix) ; 
dbras_scheduler . create_j ob [ j ob_name, 
j ob_type=> ' executable ' , 
job_action=> ' /u01/app/ext_bacfcup ' , 
nuniber_of_arguinentE=>0 , 
enabled=> false) ; 

dbms_scheduler . set_at tribute [ job_name, ' destination' , destinations (i) ] ; 

dbras_scheduler . set_at tribute [ job_name, ' credential_naine ' , 'remote_cred' ) ; 

dbiiis_scheduler .enable [job_naiiie) ; 
end loop; 
end; 
/ 

Example 3 

The example illustrates how a remote external job can submit SQL statements to a 
remote Oracle database. The job action runs a shell script that uses SQL'Plus to submit 
the statements. The script must reside on the remote host. The script, shown below, 
starts bv setting all environment variables required to run SQL'Plus on Linux, 

To avoid hard-coding a database password in the script, external authentication is 
used, 

l!/bin/sh 

export ORACLE_HOME=/u01/app/oracle/product/11.1.0/db_l 

export ORACLE_SID=orcl 

export IJ)_LIBHARY_PATH=$LD_LIBRARY_PATH:$0RACLE_HOME/lib 

I The following command assumes external authentication 

SORACLE_HOME/bin/sqlplus / « EOF 

set serveroutput on; 

select * from dual ; 

EXIT; 

EOF 

See Also: 

■ Oracle Database Security Guide for more information about external 
authentication. 

■ "About Remote External Jobs" on page 26-12 

■ "Capturing Standard Error Output for External Jobs" on page 27-9 

■ "Stopping External Jobs" on page 27-10 



Copying Jobs 



You copy a job using the COPY_JOB procedure or Enterprise Manager, This call copies 
all the attributes of the old job to the new job except the new job is created disabled 
and has another name. 
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See Oracle Database PL/SQL Packages and Types Reference for detailed information about 
the COPY_JOB procedure. 



Altering Jobs 



You alter a job using the SET_ATTRIBUTE or SET_JOB_ATTRIBUTES procedures or 
Enterprise Manager All jobs can be altered, and, with the exception of the job name, 
all job attributes can be changed. If there is a running instance of the job when the 
change is made, it is not affected by the call. The change is only seen in future runs of 
the job. 

In general, you should not alter a job that was automatically created for vou bv the 
database. Jobs that were created bv the database have the column SYSTEM set to TRUE 
in job views. The attributes of a job are available in the *_SCHEDULER_JOBS views. 

It is perfectly valid for running jobs to alter their own job attributes, however, these 
changes will not be picked up until the next scheduled run of the job. 

See Oracle Database PL/SQL Packages and Types Reference for detailed information about 
the SET_ATTRIBUTE and SET_JOB_ATTRIBUTES procedures and "Configuring 
Oracle Scheduler" on page 28-1. 



Running Jobs 



Normally, jobs are executed asvnchronously. The user creates a job and the API 
immediately returns and indicates whether the creation was successful. To find out 
whether the job succeeded, the user has to quen' the job table or the job log. While this 
is the expected behavior, for special cases, the database also allows users to run jobs 
synchronously. 

Running Jobs Asynchronously 

You can schedule a job to run asynchronously based on the schedule defined when the 
job is created. In this case, the job is submitted to the job coordinator and is picked up 
bv the job slaves for execution. 

Running Jobs Synchronousiy 

After a job has been created, you can run the job synchronously using the RUISI_JOB 
procedure with the use_current_session argument set to TRUE. In this case, the 
job will run within the user session that invoked the RUN_JOB call instead of being 
picked up by the coordinator and being executed by a job slave. 

You can use the RUN_ JOB procedure to test a job or to run it outside of its specified 
schedule. Running a job with RUN_JOB with the use_current_session argument 
set to TRUE does not change the count for f ailure_count and run_count for the 
job. The job run will, however, be reflected in the job log. Runtime errors generated by 
the job are passed back to the invoker of RUN_ JOB. 

When using RUN_JOB to run a job that points to a chain, use_current_session 
must be set to FALSE, 

Job Run Environment 

Jobs are run with the privileges that are granted to the job owner directly or indirectly 
through default logon roles. External OS roles are not supported. Given sufficient 
privileges, users can create jobs in other users' schemas. The creator and the owner of 
the job can, therefore, be different. For example, if user j im has the CREATE ANY JOB 
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privilege and creates a job in the scott schema, then the job will run with the 
privileges of scott. 

The NLS environment of the session in which the job was created is saved and is used 
when the job is being executed. To alter the NLS environment in which a job runs, a 
job must be created in a session with different NLS settings. 

Capturing Standard Error Output for External Jobs 

When a local external job or remote external job writes output to s tderr, the first 200 
bytes are recorded in the ADDITIONAL_INFO column of the 
*_SCHEDULER_JOB_RUN_DETAILS views. The information is in the following 
name/value pair format: 

STANDARD ERROR=" text" 



Note: The ADDITIONAL_INFO column can have multiple 
name/value pairs. The order is indeterminate, so you must parse the 
field to locate the STANDARD_SRROR name/value pair. 



To retrieve the entire standard error text, you can use the 

DBMS_ SCHEDULER . GET_FILE procedure. See Orach Database PL/SQL Packages and 
Types Reference for detailed information about this procedure. 



Stopping Jobs 



You stop one or more running jobs using the STOP_J0B procedure or Enterprise 
Manager, STOP_JOB accepts a comma-delimited list of jobs and job classes. If a job 
class is supplied, all running jobs in the job class are stopped. For example, the 
following statement stops job jobl and all jobs in the job class dw_jobs, 

EEGIH 

DBMS_3CHEDUI£R .STOP_JOB ( ' j obi , sys . dw_j obs ' } ; 

END; 

/ 

All instances of the designated jobs are stopped. After stopping a job, the state of a 
one-time job is set to STOPPED, and the state of a repeating job is set to SCHEDULED 
(because the next run of the job is scheduled). In addition, an entrv is made in the job 

log withOPERATIOHsetto 'STOPPED', and ADDITIOHAL_INFO set to 
'REAS0N= " stop job called by user: username''. 

By default, the Scheduler tries to gracefully stop a job using an interrupt mechanism. 
This method gives control back to the slave process, which can collect statistics of the 
job run. If the force option is set to TRUE, the job is abruptly terminated and certain 
runtime statistics might not be available for the job run. 

If coinniit_semantics is set to STOP_ON_FIRST_ERR0R, then the call returns on the 
first error and the previous stop operations that were successful are committed to disk. 
If coniniit_ semantics is set to ABSORB_ERR0RS, then the call tries to absorb any 
errors and attempts to stop the rest of the jobs and commits all the stop operations that 
were successful. By default, commit_semantics is set to STOP_ON_FIRST_ERROR, 

Stopping a job that is running a chain automatically stops all running steps (by calling 
STOP_JOB with the force option set to TRUE on each step). 

See Oracle Database PL/SQL Packages and Types Reference for detailed information about 
the STOP_JOB procedure. 
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Caution: When a job is stopped, only the current transaction is 
rolled back. This can cause data inconsistencv. 



Stopping External Jobs 

The Scheduler offers iniplementors of external jobs a mechanism to gracefully clean up 
after their external jobs when STOP_JOB is called with force set to FALSE. On Unix, 
this is done by sending a SIGTERM signal to the process launched bv the Scheduler 
agent. The implementor of the external job is expected to trap the SIGTERM in an 
interrupt handler, clean up whatever work the job has done, and exit. On Windows, 
STOP_JOB with force set to FALSE is supported only on Windows XP, Windows 
2003, and later operating systems. On those platforms, the process launched bv the 
Scheduler agent is a console process. To stop it, the Scheduler sends a CTRL -BREAK to 
the process. The CTRL_BREAK can be handled by registering a handler with the 
SetConsoleCtrlHandler ( ) routine. 



Dropping Jobs 



You drop one or more jobs using the DROP_JOB procedure or Enterprise Manager. 
DROP_JOB accepts a comma-delimited list of jobs and job classes. If a job class is 
supplied, all jobs in the job class are dropped, although the job class itself is not 
dropped. 

For example, the following statement drops jobs jobl and jobs, and all jobs in job 
classes jobcla-ssl and jobclaEE2: 

BEGIH 

DBMS_SCHEDtJLER.DROP_JOB ('jobl, job3, sys . jobclassl, sys . jobclass2 ' ) ; 

END; 

/ 

Dropping a job results in the job being removed from the job table, its metadata being 
removed, and it no longer being visible in the *_SCHEDULER_JOBS views. Therefore, 
no more runs of the job will be executed. 

If an instance of the job is running at the time of the DROP_JOB call, the call results in 
an error You can still drop the job by setting the force option in the call to TRUE, 
Setting the force option to TRUE first attempts to stop the running job instance by 
using an interrupt mechanism (bv calling STOP_JOB with the force option set to 
FALSE), and then drops the job. 

Alternatively, you can call STOP_JOB to first stop the job and then call DROP_JOB to 
drop it. If you have the MAHAGE SCHEDULER privilege, you can call STOP_J0B with 
force, if the regular STOP_ JOB call failed to stop the job, and then call DROP_ JOB, 

By default, force is set to FALSE, 

If commit_Eemantics is set to STOP_ON_FIR3T_ERR0R, then the call returns on the 
first error and the previous drop operations that were successful are committed to 
disk. If commit_semantics is set to TRANSACTIONAL and force is set to FALSE, 
then the call returns on the first error and the previous drop operations before the 
error are rolled back. If commi t_3emantics is set to ABSORB_ERRORS, then the call 
tries to absorb any errors and attempts to drop the rest of the jobs and commits aU the 
drops that were successful. By default, commi t_semanticE is set to 
STOP_ON_FIRST_ERROR, 

TheDROP_JOB_CLASS procedure should be used to drop a job class. See "Dropping 
Job Classes" on page 27-22 for information about how to drop job classes. 
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See Oracle Database PL/SQL Packages and Types Reference for detailed information about 
the DROP_JOB procedure. 



Disabling Jobs 



You disable one or more jobs using the DI SABLE procedure or Enterprise Manager A 
job can also become disabled for other reasons. For example, a job will be disabled 
when the job class it belongs to is dropped. A job is also disabled if either the program 
or the schedule that it points to is dropped. Note that if the program or schedule that 
the job points to is disabled, the job will not be disabled and v/Ul therefore result in an 
error when the Scheduler tries to run the job. 

Disabling a job means that, although the metadata of the job is there, it should not run 
and the job coordinator will not pick up these jobs for processing. When a job is 
disabled, its state in the job table is changed to disabled. 

When a job is disabled with the force option set to FALSE and the job is currently 
running, an error is returned. When force is set to TRUE, the job is disabled, but the 
currently running instance is allowed to finish. 

If comniit_semantics is set to STOP_ON_FIRST_ERR0R, then the call returns on the 
first error and the previous disable operations that were successful are committed to 
disk. If commit_seniantics is set to TRANSACTIONAL and force is set to FALSE, 
then the call returns on the first error and the previous disable operations before the 
error are rolled back. If commi t_semantics is set to ABSORB_ERRORS, then the call 
tries to absorb any errors and attempts to disable the rest of the jobs and commits all 
the disable operations that were successful. By default, commi t_semantics is set to 
STOP_ON_FIRST_ERROR. 

You can also disable several jobs in one call by providing a comma-delimited list of job 
names or job class names to the DI SABLE procedure call. For example, the following 
statement combines jobs with job classes: 

BEGIN 

DBMS_SCHEDULER.DISABLE(' jobl, job2, job3, sys. jobclassl, sys. jobclass2 ' ) ; 

EKD; 

/ 

See Orach Database PL/SQL Packages and Types Reference for detailed information about 
the DISABLE procedure. 



Enabling Jobs 



You enable one or more jobs by using the ENABLE procedure or Enterprise Manager. 
The effect of using this procedure is that the job will now be picked up by the job 
coordinator for processing. Jobs are created disabled by default, so vou need to enable 
them before they can run. When a job is enabled, a \'alidity check is performed. If the 
check fails, the job is not enabled. 

If commi t_semantics is set to STOP_ON_FIRST_ERR0R, then the call returns on the 
first error and the previous enable operations that were successful are committed to 
disk. If commit_semantics is set to TRANSACTIONAL, then the call returns on the 
first error and the previous enable operations before the error are rolled back. If 
commi t_semantics is set to ABSORB_ERRORS, then the call tries to absorb any errors 
and attempts to enable the rest of the jobs and commits all the enable operations that 
were successful, Bv default, commi t_semantics is set to STOP_ON_FIRST_ERROR. 
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You can enable several jobs in one call by providing a comma-deli mi ted list of job 
names or job class names to the ENABLE procedure call. For example, the following 
statement combines jobs with job classes: 

BEGIH 

DBMS_SCHEa]DLER.MABLE ('jobl, job2, job3, 

sys . jobclassl, sys . jcibclass2 , sys . jobclassS ' ) ; 
END; 
/ 

See Oracle Database PL/SQL Packages and Types Reference for detailed information about 
the ENABLE procedure. 



Using Programs 



A program is a collection of metadata about a particular task. This section introduces 
you to basic program tasks, and discusses the following topics: 

Program Tasks and Their Procedures 

Creating Programs 

Altering Programs 

Dropping Programs 

Disabling Programs 

Enabling Programs 

See Also: "Programs" on page 26-3 for an overview of programs. 



Program Tasks and Their Procedures 



Table 27-2 illustrates common program tasks and their appropriate procedures and 
privileges: 

Table 27-2 Program Tasks and Their Procedures 



Task 



Procedure 



Privilege Needed 



Create a program CREATE_PROGRAM CREATE JOB or CREATE AMY JOB 

Alter a program 3ET_ATTRIBUTE ALTER or CREATE AMY JOB or be the owner 

Drop a program DROP_PR0GRAM ALTER or CREATE AMY JOB or be the owner 

Disable a program DISABLE ALTER or CREATE AMY JOB or be the owner 

Enable a program ENABLE ALTER or CREATE AMY JOB or be the owner 

See "Scheduler Privileges" on page 28-30 for further information regarding privileges. 



Creating Programs 



You create programs bv using the CREATE_PROGRAM procedure or Enterprise 
Manager, Bv default, programs are created in the schema of the creator To create a 
program in another user's schema, vou need to qualify the program name with the 
schema name. For other users to use vour programs, thev must have EXECUTE 
privileges on the program, therefore, once a program has been created, you have to 
grant the EXECUTE privilege on it. An example of creating a program is the following, 
which creates a program called mY_progranil: 
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BEGIN 

DBMS_SCHEa3ULER.CEEATE_PE0GRM ( 

program_name => 'n^_programl ' , 

program_actioii => ' /'UEr/local/bin/date ' , 

program_type => 'EXECUTABLE', 

conments => 'My comments here'); 

END; 
/ 

Defining Program Arguments 

After creating a program, vou can define a name or default value for each program 
argument. If no default value is defined for a program argument, the job that 
references the program must suppiv an argument value, (The job can also override a 
default value.) All argument values must be defined before the job can be enabled. 

To set program argument values, use the DEFINE_PROGRAM_ARGUMENT or 

DEFINE_ANYDATA_ARGUMENT procedures, DEFINE_ANYDATA_ARGUMENT is used for 

complex types that must be encapsulated in an ANYDATA object. An example of a 
program that might need arguments is one that starts a reporting program that 
requires a start date and end date. The following code example sets the end date 
argument, which is the second argument expected bv the reporting program. The 
example also assigns a name to the argument so that you can refer to the argument bv 
name (instead of position) from other package procedures, including 

SET_JOB_ANYDATA_VALUE and SET_JOB_ARGUMENT_VALUE, 

BEGIH 

DBMS SCHEDULER. DEFINE PROGRAM MGIJMENT ( 





pr ogr anuname 




=> 


operationE_r 




ar gument_pos i t 


ion 


=> 


2, 




argument_naiiie 




=> 


' erid_date' , 




ar guinen t_ty p e 




=> 


' VARCHflR2 ' , 




default value 




=> 


'12-DEC-03') ; 


END; 









You can drop a program argument either by name or by position, as in the following: 

BEGIN 
DBMS_SCHEDULER.DEOP_PROGRAH_ARGUMEHT ( 

prograin_name => ' opera tionE_repor ting ' , 

argument_poEition => 2); 

DBMS_SCHEDULER.DEOP_PROGRAM_ARGUMENT ( 

program_naine => ' opera tionE_repor ting ' , 

argument_nanie => 'end_date'); 

END; 
/ 

In some special cases, program logic is dependent on the Scheduler environment. The 
Scheduler has some predefined metadata arguments that can be passed as an 
argument to the program for this purpose. For example, for some jobs whose schedule 
is a window name, it is useful to know how much longer the window will be open 
when the job is started. This is possible by defining the window end time as a 
metadata argument to the program. 

If a program needs access to specific job metadata, you can define a special metadata 
argument using the DEFINE_METADATA_ARGUMENT procedure, so values will be 
filled in by the Scheduler when the program is executed. 
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See Also: Oracle Database PL/SQL Packages and Types Reference for 
detailed information about the DEFIHE_PROGRAM_ARGUMENT, 

DEFINE_ANYDATA_ARGUMENT, and 
DEFINE_METADATA_ARGUMENT procedures 



Altering Programs 



You can use Enterprise Manager or the DBMS_SCHEDULER . SET_ATTRIBUTE and 
DBMS_ SCHEDULER . SET_ATTRIBUTE_NULL package procedures to alter programs. 
See Orach Database PL/SQL Packages and Types Reference for more information on the 
DBMS_ SCHEDULER package procedures. 

The following are instructions for altering a program with Enterprise Manager: 

1. Access the Database Home page. 

2. At the top of the page, click Server to display the Server page, 

3. In the Oracle Scheduler section, click Programs 

The Scheduler Programs page appears. It displays existing programs. 

4. Select a program, and then click Edit, 
The Edit Program page appears. 

5. Next to the Enabled heading, select Yes or No. 

6. In the Description field, change any comments. 

7. From the Tvpe drop-down list, select one of the following: 

■ pr.SQr._Br.ocK 

A Source field appears. Enter or alter the PL /SQL code in this field. 

■ S TORE D_P ROC E DURE 

A Procedure Name field appears. If the field contains a stored procedure 
name, click View Procedure to view or edit the stored procedure. If the field is 
blank, or if you want to change stored procedures, click Select Procedure, A 
Select Procedure page then appears. Select a stored procedure and then click 
Select to return to the Edit Program page, (Click Help at the top of the page 
for help with using the Select Procedure page,) 

With a procedure name selected, a list of arguments appears under the 
Arguments heading on the Edit Program page. Optionally enter default values 
for one or more arguments, 

■ EXECUTABLE 

An Executable Name field appears. Enter the full path of the executable. 
Under the Arguments heading, edit or delete arguments, or click Add 
Another Row to add an argument, 

8. Click Apply to save vour changes. 

If any currently running jobs use the program that you altered, they continue to run 
with the program as defined before the alter operation. 



Dropping Programs 



You drop one or more programs using the DROP_PROGRAM procedure or Enterprise 
Manager, 
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Running jobs that point to the program are not affected by the DROP_PROGRAM call, 
and are allowed to continue, Anv arguments that pertain to the program are also 
dropped when the program is dropped. You can drop several programs in one call by 
providing a comma-delimited list of program names. For example, the following 
statement drops three programs: 

EEGIH 

DBMS_3CHEDUI£R.DE0P_PR0GRM{'programl, prograin2 , programs'}; 

EKD; 

/ 

See Oracle Database PL/SQL Packages and Types Reference for detailed information about 
Ihe DROP_PROGRAM procedure. 



Disabling Programs 



You disable one or more programs using the DISABLE procedure or Enterprise 
Manager, When a program is disabled, the status is changed to disabled. A disabled 
program implies that, although the metadata is still there, jobs that point to this 
program cannot run. 

Running jobs that point to the program are not affected by the DI SABLE call, and are 
allowed to continue. Any argument that pertains to the program will not be affected 
when the program is disabled, 

A program can also become disabled for other reasons. For example, if a program 
argument is dropped or number_of _arguments is changed so that all arguments are 
no longer defined. 

See Orach Database PL/SQL Packages and Types Reference for detailed information about 
the DISABLE procedure. 



Enabling Programs 



You enable one or more programs using the ENABLE procedure or Enterprise 
Manager. When a program is enabled, the enabled flag is set to TRUE, Programs are 
created disabled bv default, therefore, you have to enable them before you can enable 
jobs that point to them. Before programs are enabled, validity checks are performed to 
ensure that the action is valid and that all arguments are defined. 

You can enable several programs in one caU by providing a comma-delimited list of 
program names to the ENABLE procedure call. For example, the following statement 
enables three programs: 

EEGIH 

DBMS_3CHEDULER.E2JABLE[ 'progranil, program2, programs'); 

EKD; 

/ 

See Oracle Database PL/SQL Packages and Types Reference for detailed information about 
the ENABLE procedure. 



Using Schedules 



A schedule defines when a job should be run or when a window should open. 
Schedules can be shared among users by creating and saving them as objects in the 
database. 

This section introduces you to basic schedule tasks, and discusses the following topics: 
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Schedule Tasks and Their Procedures 
Creating Schedules 
Altering Schedules 
Dropping Schedules 
Setting the Repeat Interval 

See Also: "Schedules" on page 26^ for an overview of schedules. 



Schedule Tasks and Their Procedures 



Table 27-3 illustrates common schedule tasks and the procedures vou use to handle 
them. 

Table 27-3 Schedule Tasks and Their Procedures 

Task Procedure Privilege Needed 

Creiite a schedule CSEATE_S CHEDULE CREATE JOB or CREATEftUY JOB 

Alter d schedule SET_ATTRIBUTE ALTER or CREATE AMY JOB or be the owner 

Drop a schedule DR0P_3CHEDDLE ALTER or CREATE AMY JOB or be the owner 

See "Scheduler Privileges" on page 28-30 for further information regarding privileges. 



Creating Schedules 



You create schedules by using the CREATE_SCHEDULE procedure or Enterprise 
Manager, Schedules are created in the schema of the user creating the schedule, and 
are enabled when first created. You can create a schedule in another user's schema. 
Once a schedule has been created, it can be used bv other users. The schedule is 
created v^fith access to PUBLIC. Therefore, there is no need to explicitlv grant access to 
the schedule. An example of creating a schedule is the following statement: 

BEGIM 
DBMS_3CHEDULER.CEEATE_SCHEDULE ( 

schedule_nairLe => 'my_stats_schedule ' , 

start_date => SYSTIMESTAMP , 

end_date => SYSTIMESTAMP + IMTERVAL '30' day, 

repeat_interval => 'FREQ=HOURL¥; IHTERVAL=4', 

comments => 'Every 4 hours ' ) ; 
END; 
/ 

See Oracle Database PL/SQL Packages and Types Reference for detailed information about 
the CREATE_SCHEDULE procedure. 



Altering Schedules 



You alter a schedule by using the SET_ATTRIBUTE procedure or Enterprise Manager 
Altering a schedule changes the definition of the schedule. With the exception of 
schedule name, all attributes can be changed. The attributes of a schedule are available 
in the --.SCHEDULER.SCHEDULES views, 

If a schedule is altered, the change will not affect running jobs and open windows that 
use this schedule. The change will onlv be in effect the next time the jobs runs or the 
window opens. 
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See Oracle Database PL/SQL Packages and Types Refercna for detailed information about 
the SET_ATTRIBUTE procedure. 



Dropping Schedules 



YoLL drop a schedule using the DROP_SCHEDULE procedure or Enterprise Manager. 
This procedure call will delete the schedule object from the database. 

See Oracle Database PL/SQL Packages and Types Reference for detailed information about 
the DROP_SCHEDULE procedure. 



Setting the Repeat Interval 



You control when and how often a job repeats by setting the repeat_interval 
attribute of the job itself or of the named schedule that the job references. You can set 
repeat:_interval with DBMS_SCHEDULER package procedures or with Enterprise 
Manager, 

The result of evaluating the repeat_interval is a set of timestamps. The Scheduler 
runs the job at each timestamp. Note that the start date from the job or schedule also 
helps determine the resulting set of timestamps, (See Oracle Database PL/SQL Packages 
ami Types Reference for more information about repeat_interval evaluation,) If no 
value for repeat_interval is specified, thejob runs only once at the specified start 
date. 

Immediately after a job is started, the repeat_interval is evaluated to determine 
the next scheduled execution time of the job. It is possible that the next scheduled 
execution time arrives while the job is still running, A new instance of the job, 
however, will not be started until the current one completes. 

There are two ways to specify the repeat interval: 

■ Using the Scheduler Calendaring Syntax 

■ Using a PL/SQL Expression 

Using the Scheduler Calendaring Syntax 

The primary method of setting how often a job will repeat is by setting the 
repeat_interval attribute with a Scheduler calendaring expression. See Oracle 
Database PL/SQL Packages and Types Reference for a detailed description of the 
calendaring syntax for repeat_interval as well as the CREATE_SCHEDULE 
procedure. 

Examples of Calendaring Expressions 

The following examples illustrate simple repeat inter\'alB, For simplicit}', it is assumed 
that there is no contribution to the evaluation results bv the start date. 

Run every Friday, (All three examples are equivalent.) 

FREQ=DAILYr BYDAY=FRIr 
FEEQ=MEEKLYr BYDAY=FRIr 
FEEQ=YEMLYr BYDAY=FRIr 

Run every other Friday. 

FREQ=WEEKLY,- INTER"VAL=2 ; BYDAY=FRIr 

Run on the last day of everv month. 

FREQ=MONTHLY; BYMON'FHDAY= - 1 ; 
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Run on the next to last day of every month. 

JEEQ=MONTHLY; BYMONTHDAY= - 2 ; 

Run on March 10th, (Both examples are equivalent) 

FEEQ=YEaRLY,- BYHOHTH=MftE ; BYMONTHDAY= 1 ; 
FREQ=YEAELYr BYDATE=0310; 

Run every 10 days. 

PEEQ=DAILY; INTERVAL=10; 

Run daily at 4, 5, and 6PM. 

™EQ=DAILY; BYH0UR=15,17,18; 

Run on the 15th day of every other month. 

PM;Q=M0HTHLY; IHTERVAL=2; BYM0HTHDAY= 1 5 ; 

Run on the 29th day of every month. 

PEEQ=MOHTHLY; BYMONTHDAY= 2 9 ; 

Run on the second Wednesday of each month. 

PEEQ=MONTHLY; BYDAY=2WED; 

Run on the last Friday of the year. 

PKEQ=YEARLYr BYDAY=-1FRI; 

Run every 50 hours, 

PEEQ=HOUELYr INTERVAL=50; 

Run on the last dav of everv other month, 

PEEQ=MOHTHLY; IHTERVAL=2; BYM0NTHDAY=-1; 

Run hourly for the first three days of everv month, 

ZREQ=HOHELYr BYMONTHDAY= 1 , 2 , 3 ; 

Here are some more complex repeat intervals: 

Run on the last workday of every month (assuming that workdays are Monday 
through Friday), 

PEEQ=MONTHLY; BYDAY=MOH , TUE , lED , THH , FRI ; BY3ETP0S=-1 

Run on the last workday of every month, excluding company holidays, (This example 
references an existing named schedule called CompanY_HolidaYs,) 

FREQ=MOHTHLY; BYDAY=MOH , TUE , lED , THO , FRI ; EXCLDDE=Corapany_HolidayE ; BY3ETP0S=-1 

Run at noon every Friday and on company holidays, 

FREQ=YEARLY;BYDAY=FTiI;BYH0UE=12;INCLUDE=Company_HolidayE 

Run on these three holidays; July 4th, Memorial Day, and Labor Day, (This example 
references three existing named schedules — JUL4, MEM, and LAB — where each defines 
a single date corresponding to a holiday) 
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JUL4,MEM,LAB 

Examples of Calendaring Expression Evaluation 

A repeat inten'al of "FREQ=MINUTELY; INTERVAL=2 ;BYHOUR=n ; 

BYMINUTE=2.4. 5.50. 51 . 7 ;" with a start date of 28-FEB-2004 23:00:00 wiU generate 
the foUowing schedule: 

SUM 29-FEB-2004 17:02:00 
SUM 29-FEB-2004 17:04:00 
SUM 29-FEB-2004 17:50:00 
MON Ol-MAR-2004 17:02:00 
MOM Ol-MAR-2004 17:04:00 
MOM Ol-MAR-2004 17:50:00 



A repeat inten'al of "FREQ=M0NTHLY;BYM0NTHDAY=15 . -1" with a start date of 
29-DEC-2003 9:00:00 will generate the following schedule: 

WED 31-DEC-2003 09:00:00 

THU 15-JAM-2004 09:00:00 

SAT 31-JAM-2004 09:00:00 

SUN 15-FEB-2004 09:00:00 

SUN 29-FEB-2004 09:00:00 

MON 15-MAR-2004 09:00:00 

WED 31-MAR-2004 09:00:00 



A repeat interval of "FREQ=MOWTHLY; " with a start date of 29-DEC-2003 9:00:00 will 
generate the following schedule, (Note that because there is no BYMONTHDAY clause, 
the day of month is retrieved from the start date.) 

MON 29-DEC-2003 09:00:00 
THU 29-JAM-2004 09:00:00 
SUM 29-FEB-2004 09:00:00 
MON 29-MAR-2004 09:00:00 



Example o1 Using a Calendaring Expression 

As an example of using the calendaring syntax, consider the following statement: 

BEGIN 

dbms_sc:heduler.ceeate_job ( 

3cott.my_jobl ' , 

15-JUL-04 01.00.00 AM Europe/Warsaw', 
FREQ=MIHUTELYr INTERVAL=30; ' , 
15-SEP-04 01.00.00 AM Europe/Warsaw', 
My coninerits here ' ) ; 



This creates my_j obi in scott. It will run for the first time on July 15th and then run 
until September 15, The job is run every 30 minutes. 

Using a PL/SOL Expression 

When you need more complicated capabilities than the calendaring svntax provides, 
you can use PL/SQL expressions. You. cannot, however, use PL/SQL expressions for 
windows or in named schedules. The PL/SQL expression must evaluate to a date or a 
timestamp. Other than this restriction, there are no limitations, so with sufficient 



j ob_name 


=> 


start date 


=> 


repeat_interval 


=> 


end_date 


=> 


comments 


=> 


EKD; 




/ 
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BEGIH 




DBMS_3CHEDUI£R. CREATE. 


_JOB ( 


j ob_name 


=> 


start date 


=> 


repeat_interval 


=> 


end._date 


=> 


comments 


=> 


END; 
/ 





programmmg, vou can create every possible repeat interval. As an example, consider 
the following statement; 



scott.my_job2 ' , 

15-JUL-04 01.00.00 AM Eur ope /Wars aw ' 
3YSTIMESTMP + INTERVAL '30' MINUTE' 
15-SEP-04 01.00.00 AM Eur ope /Wars aw ' 
My coinnents here ' ) ; 



This creates mY_j obi in scott. It will run for the first time on July 15th and then 
every 30 minutes until September 15, The job is run every 30 minutes because 

repeat_interval is setto SYSTIMESTAMP + INTERVAL '3D' MINUTE, which 
returns a date 30 minutes into the future. 

Differences Between PL/SQL Expression and Calendaring Syntax Behavior 

The following are important differences in behavior between a calendaring expression 
and PL/SQL repeat interval: 

■ Start date 

Using the calendaring svntax, the start date is a reference date only. This means 
that the schedule is valid as of this date. It does not mean that the job will start on 
the start date. 

Using a PL /SQL expression, the start date represents the actual time that the job 
will start executing for the first time. 

■ Next run time 

Using the calendaring syntax, the next time the job will run is fixed. 

Using the PL /SQL expression, the next time the job will run depends on the actual 
start time of the current run of the job. As an example of the difference, if a job 
started at 2:00 PM and its schedule was to repeat every 2 hours, then, if the repeat 
interval was specified with the calendaring syntax, it would repeat at 4, 6 and so 
on. If PL/SQL was used and the job started at 2:10, then the job would repeat at 
4:10, and if the next job actually started at 4:11, then the subsequent run would be 
at 6:11. 

To illustrate these two points, consider a situation where you have a start date of 
15-July-2003 1:45:00 and you want it to repeat every two hours, A calendar expression 

of "FREQ=HOURLY,- INTERVAL= 2 ; BYMINUTE= D ; " will generate the following 
schedule: 

TUE 15-JUL-2003 03:00:00 

TUE 15-JUL-2003 05:00:00 

TUE 15-JUL-2003 07:00:00 

TUE 15-JUL-2003 09:00:00 

TUE 15-JUL-2003 11:00:00 



Note that the calendar expression repeats everv two hours on the hour. 

A PL/SQL expression of "SYSTIMESTAMP + interval '2' hour", however, 
might have a run time of the following: 

TUE 15-JUL-2003 01:45:00 
TUE 15-JUL-2003 03:45:05 
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TDE 15-JUL-2003 05:45:09 
TUE 15-JUL-2003 07:45:14 
TUE 15-JUL-2003 09:45:20 



Repeat Intervals and Daylight Savings 

For repeating jobs, the next time a job is scliediiled to run is stored in a time stamp with 
time zone column. Wlien using tlie calendaring syntax, tlie time zone is retrieved from. 
start_date. For more information on what happens when s tart_date is not 
specified, see Oracle Database PL/SQL Packages and Types Reference. 

In the case of repeat intervals that are based on PL /SQL expressions, the time zone is 
part of the timestamp that is returned by the PL/SQL expression. In both cases, it is 
important to use region names. For example, " Europe/Istanbul ", instead of 
absolute time zone offsets such as "+2:00", Onh' when a time zone is specified as a 
region name will the Scheduler follow daylight savings adjustments that applv to that 
region. 



Using Job Classes 



Jobs classes provide a way to group jobs for resource allocation and prioritization, and 
a way to easily assign a set of attribute values to member jobs. 

There is a default job class that is created with the database. If you create a job without 
specifying a job class, the job will be assigned to this default job class 
(DEFAULT_JOB_CLASS) , The default job class has the EXECUTE privilege granted to 
PUBLIC SO any database user who has the privilege to create a job can create a job in 
the default job class. 

This section introduces you to basic job class tasks, and discusses the following topics: 

■ Job Class Tasks and Their Procedures 

■ Creating Job Classes 

■ Altering Job Classes 

■ Dropping Job Classes 

See Also: "Job Classes" on page 26-8 for an overview of job classes. 



Job Class Tasks and Their Procedures 



Table 27—1 illustrates common job class tasks and their appropriate procedures and 
privileges: 

Table 27-4 Job Class Tasks and Their Procedures 

Task Procedure Privilege Needed 

Create n job class CREATE_JOB_CLAS S MANAGE SCHEDDLER 

Alter a job class SET_ATTRIBUTE MANAGE SCHEDULER 

Drop ajob class DROP_JOB_CLASS MANAGE SCHEDULER 

See "Scheduler Privileges" on page 28-30 for further information regarding privileges. 
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Creating Job Classes 

YoLL create a job class using the CREATE_JOB_CLASS procedure or Enterprise 
Manager For example, the following statement creates a job class for all finance jobs: 

BEGIH 
DBMS_SCHEDiri£R.CEEATE_JOB_CLftSS ( 

j Db_class_name => ' f inaiice__jabs ' , 

resource_conH"uiiLer_group => ' f inane e_group ' ] ; 
END; 
/ 

To query job classes, use the ■•_SCHEDULER_JOB_CLASSES views. 

See Oracle Database PL/SQL Packages and Types Reference for detailed information about 
the SET_ATTRIBUTE procedure and "Configuring Oracle Scheduler" on page 28-1 for 
examples of creating job classes. 



Altering Job Classes 



You alter a job class by using the SET_ATTRIBUTE procedure or Enterprise Manager 
Other than the job class name, all the attributes of a job class can be altered. The 
attributes of a job class are available in the '_SCHEDULEE_JOB_CLASSES views. 

When a job class is altered, ruruiing jobs that belong to the class are not affected. The 
change only takes effect for jobs that have not started running yet. 

See OracL: Database PL/SQL Packages and Types Reference for detailed information about 
the SET_ATTRIBUTE procedure and "Configuring Oracle Scheduler" on page 28-1, 



Dropping Job Classes 



You drop one or more job classes using the DROP_JOB_CLASS procedure or 
Enterprise Manager, Dropping a job class means that all the metadata about the job 
class is removed from the database. 

You can drop several job classes in one call by providing a comma-delimited list of job 
class names to the DROP_JOB_CLASS procedure call. For example, the following 
statement drops three job classes: 

BEGIN 

DfflS_SCHEDDLER.DROP_JOB_CLASS[ ' jobclassl, jobclasE2, jobclassS'); 

END; 

/ 

See Oracle Database PL/SQL Packages and Types Reference for detailed iiJormation about 
the DROP_JOB_CLASS procedure. 



Using Windows 



Windows provide a way to automatically activate different resource plans at different 
times. Running jobs can then see a change in the resources that are allocated to them 
when there is a change in resource plan. 

The key attributes of a window are its: 

■ Schedule 

This controls when the window^ is in effect, 

■ Duration 
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This controls how long the window is open, 

■ Resource plan 

This names the resource plan that activates when the window opens. 

Only one window can be in effect at any given time. Windows belong to the SYS 
schema. 

All window activity is logged in the ■'_SCHEDULER_WIwr>OW_LOG views, otherwise 
known as the window logs. See "Window Logs" on page 28-10 for examples of 
window logging. 

This section introduces you to basic window tasks, and discusses the following topics: 

Window Tasks and Their Procedures 

Creating Windows 

Dropping Windows 

Opening Windows 

Closing Windows 

Dropping Windows 

Disabling Window^s 

Enabling Windows 

Overlapping Windows 

See Also: "Windows" on page 26-9 for an overview of windows. 



Window Tasks and Their Procedures 



Table 27-5 illustrates common w^indow tasks and the procedures vou use to handle 
them. 

Table 27-5 Window Tasks and Their Procedures 



Task 



Create ^ window 
Open l1 window 
Close a window 
Alter a window 
Drop a window 
Disable a window 
Enable a window 



Procedure 



Privilege Needed 



CREATE_WINDOW 

OPEH_WIHDOW 

CLOSE_WIHDOW 

SET_ATTRIBUTE 

DR0P_Wim)OW 

DISABLE 

ENABLE 



MANAGE SCHEDULER 
MANAGE SCHEDULER 
MANAGE SCHEDULER 
MANAGE SCHEDULER 
MANAGE SCHEDULER 
MANAGE SCHEDULER 
MANAGE SCHEDULER 



See "Scheduler Privileges" on page 28-30 for further information regarding privileges. 



Creating Windows 



You can use Enterprise Manager or the DBMS_SCHEDULER . CREATE_MIWDOM package 
procedure to create windows. There is one difference between these methods, other 
than the fact that one uses PL/SQL, and the other a graphical user interface. When 
using the package procedure, vou can leave the resource_plan parameter NULL, In 
this case, when the window opens, the current plan remains in effect. See Oracle 
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Dalcilmse PL/SQL Packages and Ti/pt's Reference and "Configuring Oracle Scheduler" on 
page 28-1 for more information. 

The following are instructions for creating a window with Enterprise Manager: 

1. Access the Database Home page. 

2. At the top of the page, click Server to display the Server page, 

3. In the Oracle Scheduler section, click Windows. 

The Scheduler Windows page appears. It displays existing windows, 

4. Click Create, 

The Create Window page appears, 

5. Enter a name for the window, 

6. Choose a resource plan from the Resource Plan dropndown list, or create a 
resource plan. 

You can use the default, INTERNAL_PLAN, To view the contents of an existing 
resource plan, click View Resource Plan. If you choose to create a new resource 
plan, click Create Resource Plan and follow those steps, 

7. Select a priorit\'. Low or High, 

8. Enter optional comments in the Description field, 

9. Under the Schedule heading, do one of the following: 

■ To create a schedule, select Use a calendar, 

■ To use an existing schedule, select Use an existing schedule, A schedule with 
its information is displaved. If vou want a different schedule, click Select 
Schedule, in which case the Select Schedule page is displaved. Select one of 
the schedules listed under the Results heading, or enter the schema and a text 
string for the schedule name, and then click Go, The schedule with the search 
string in its name is returned. Select the desired schedule and click Select. 

Note: The Scheduler does not check if there is alreadv a window 
defined for that schedule. Therefore, this may result in windows that 
overlap. Also, using a named schedule that has a PL/SQL expression 
as its repeat interval is not supported for window^s. 

Click OK, and skip the remaining steps in this procedure, 

10. If vou want to change the time zone, click the flashlight icon next to the Time Zone 
field and follow the steps, 

11. Under the Repeating drop-down list, cKoose how often vou w^ant the window to 
repeat. If you choose a value other than Do Not Repeat, the page changes so that 
you can enter the interval and enter a starting time. 

12. Under the Start heading, select whether vou want the schedule to start 
Immediately or Later, If you choose Later, enter a date, 

13. Under the Duration heading, enter how long the window is to remain open, 

14. Chck OK to save the window. 
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Altering Windows 

YoLL alter a windovi' using the 3ET_ATTRIBUTE procedure or Enterprise Manager 
With the exception of WINDOW_NAME, alJ the attributes of a window can be changed 
when it is ahered. The attributes of a window are available in the 

*_SCHEDULER_WIHDOWS views. 

When a window is altered, it does not affect an active window. The changes only take 
effect the next time the window opens. 

All windows can be altered. If vou alter a window that is disabled, it will remain 
disabled after it is altered. An enabled window will be a u torn a tic a II v disabled, altered, 
and then reenabled, if the validity checks performed during the enable process are 
successful. 

See Oracle Database PL/SQL Packages and Types Reference for detailed informahon about 
the SET_ATTRIBUTE procedure and "Configuring Oracle Scheduler" on page 28-1. 



Opening Windows 



When a window opens, the Scheduler switches to the resource plan that has been 
associated with it during its creation. If there are jobs running when the window 
opens, the resources allocated to them might change due to the switch in resource 
plan- 
There are two ways a window can open: 

■ According to the window's schedule 

■ Manually, using the OPEW_WINDOW procedure 

This procedure opens the window independent of its schedule. This window will 
open and the resource plan associated with it will take effect immediatelv. Onlv an 
enabled window can be manuallv opened. 

In the OPEW_WIWI>OW procedure, you can specify the time interval that the 
window should be open for, using the duration attribute. The duration is of type 
interval day to second. If the duration is not specified, then the window will be 
opened for the regular duration as stored with the window. 

Opening a window manuallv has no impact on regular scheduled runs of the 
window. 

When a window that was manually opened closes, the rules about overlapping 
windows are applied to determine which other window should be op)ened at that 
time if anv at all. 

You can force a window to open even if there is one already open bv setting the 
force option to TRUE in the OP EN_WIwr>OW call or Enterprise Manager, 

When the force option is set to TRUE, the Scheduler automatically closes anv 
window that is open at that time, even if it has a higher priorit\'. For the duration 
of this manuallv opened window, the Scheduler does not open any other 
scheduled windows even if they have a higher priorit}'. You can open a window 
that is already open. In this case, the window stays open for the duration specified 
in the call, from the time the OPEN_WIIsrDOW command was issued. 

Consider an example to illustrate this, windowl was created with a duration of 
four hours. It has how been open for two hours. If at this point you reopen 
windowl using the 0PEN_WINDOW call and do not specify a duration, then 
windowl will be open for another four hours because it was created with that 
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duration. If vou specified a duration of 30 minutes, the window wilt close in 30 
minutes. 

When a window opens, an entry is made in the window log, 

A window can fail to switch resource plans if the current resource plan has been 
manually switched using the ALTER SYSTEM statement with the FORCE option, or 
using the DBMS_RESOURCE_MANAGER . SWITCH_PLAN package procedure with the 
allow_scheduler_plan_switches argument set to FALSE, In this case, the failure 
to switch resource plans is written to the window log. 

See Orade Database PL/SQL Packages and Types Reference for detailed information about 
the 0PEN_WINDOW procedure and the DBMS_RESOURCE_MAHAGER . SWITCH_PLAN 
procedure. 

Closing Windows 

There are two ways a window can close: 

■ Based on a schedule 

A window will close based on the schedule defined at creation time. 

■ Manually, using the CLOSE_WINDOW procedure 

The CLOSE_WINDOW procedure will close an open window prematurely, 

A closed window means that it is no longer in effect. When a window is closed, the 
Scheduler will switch the resource plan to the one that was in effect outside the 
window or in the case of overlapping windows to another window. If you try to close 
a window that does not exist or is not open, an error is generated. 

A job that is running will not close when the window it is running in closes unless the 
attribute stop_on_window_close was set to TRUE when the job was created. 
However, the resources allocated to the job may change because the resource plan may 
change. 

When a running job has a window group as its schedule, the job will not be stopped 
when its window is closed if another window that is also a member of the same 
window group then becomes active. This is the case even if the job was created with 
the attribute stop_on_window_close set to TRUE. 

When a window is closed, an entry will be added to the window log 

DBA_SCHEDULER_WINDOW_LOG, 

See Oracle Database PL/SQL Packages and Types Reference for detailed information about 
the CLOSE_WINDOW procedure. 



Dropping Windows 



You drop one or more windows using the DROP_WINDOW procedure or Enterprise 
Manager, When a window is dropped, all metadata about the window is removed 
from the '_SCHEDULER_WINDOWS views. All references to the window are removed 
from window groups. 

You can drop several windows in one call by providing a comma-delimited list of 
window names or window group names to the DROP_WIWDOM procedure. For 
example, the following statement drops both windows and window groups: 

BEGIH 

DBMS_3CHEDUI£R.DR0P_MIND0W ('windowl, wiridow2, 

windows, windowgroupl , windowgroup2 ' ) ; 
END; 
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/ 

Note that if a window group name is provided, then the windows in the window 
group are dropped, but the window group is not dropped. To drop the window 
group, you must use the DROP_WINriOW_GROUP procedure. 

See Oracle Database PL/SQL Packages and Types Reference for detailed information about 
the DROP_WINDOW procedure. 



Disabling Windows 



You disable one or more windows using the DI SABLE procedure or with Enterprise 
Manager This means that the window will not open, however, the metadata of the 
window is still there, so it can be reenabled. Because the DISABLE procedure is used 
for several Scheduler objects, when disabling windows, they must be preceded by 
SYS. 

A window can also become disabled for other reasons. For example, a window will 
become disabled when it is at the end of its schedule. Also, if a window points to a 
schedule that no longer exists, it becomes disabled. 

If there are jobs that have the window as their schedule, vou will not be able to disable 
the window unless you set force to TRUE in the procedure call. By default, force is 
set to FALSE. When the window is disabled, those jobs that have the window as their 
schedule will not be disabled. 

You can disable several windows in one call by providing a comma-delimited list of 
window names or window group names to the DI SABLE procedure call. For example, 
the following statement disables both windows and window groups; 

EEGIH 

DEMS_SCHEDULER. DISABLE ('sys .windowl, sys .wiridow2, 

sys .window3, sys . windowgroupl , sys .windowgroup2 ' ) ; 
END; 
/ 

See Orach Database PL/SQL Packages and Types Reference for detailed information about 
the DISABLE procedure and Admin for a list of why windows may be disabled. 



Enabling Windows 



You enable one or more windows using the ENABLE procedure or Enterprise Manager. 
An enabled window is one that can be opened, Windows are, by default, created 
enabled. When a window is enabled using the ENABLE procedure, a validitv check is 
performed and onlv if this is successful will the window be enabled. When a window 
is enabled, it is logged in the window log table. Because the ENABLE procedure is used 
for several Scheduler objects, when enabling windows, they must be preceded by SYS. 

You can enable several windows in one call by providing a comma-delimited list of 
window names. For example, the following statement enables three windows: 

EEGIH 

DBMS_SCHEDULER. ENABLE ( ' sys .windowl, sys.window2, sys .window3 ' } ; 

EHD; 

/ 

See Oracle Database PL/SQL Packages and Types Reference for detailed information about 
the ENABLE procedure. 
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Overlapping Windows 

Although Oracle does not recommend it, windows can overlap. Because oniv one 
window can be active at one time, the following rules are used to determine which 
window will be active when windows overlap: 

■ If windows of the same priority' overlap, the window that is active will stav open. 
However, if the overlap is with a window of higher priorit;', the lower priorit\' 
window will close and the window with the higher priorit\' will open. Jobs 
currentlv running that had a schedule naming the low priority window may be 
stopped depending on the behavior you assigned when you created the job. 

■ If at the end of a window there are multiple windows defined, the window with 
the highest prioritv wiU open. If all windows have the same priorit;', the window 
that has the highest percentage of time remaining will open. 

■ An open window that is dropped will be autom.atically closed. At that point, the 
previous rule applies. 

Whenever two windows overlap, an entry is written in the Scheduler log. 

Examples of Overlapping Windows 

Figure 27-1 illustrates a tvpical example of how windows, resource plans, and 
priorities might be determined for a 24 hour schedule. In the following two examples, 
assume that Windowl has been associated with Resource Planl, Window2 with 
Resource Plan2, and so on. 

Figure 27-1 Windows and Resource Plans (Example 1) 



Default 

Resource 

Plan 


Resource 
Plan 

g 1 1 


Resource 

Plan 
- 3 


Resource 
Plan 

g 1 1 


Default 

Resource 

Plan 




Resource 
Plan 2 


Resource 
Plan 

« " fe 


Default 

Resource 

Plan 






Window 3 

(HIgli Priority) 








Window 4 

(Higli Priority) 






Window 1 

(Low Priority) 


Window 2 

(High Priority) 

































12 am 



4 am 



Bam 



9 am 11 am 



2pm 3pm 



a pm 1 pm 



12 am 



In Figure 27—1, the following occurs: 

. From 12AM to 4AM 

No windows are open, so a default resource plan is in effect 

. From 4AM to 6AM 

Windowl has been assigned a low priority, but it opens because there are no high 
priority windows. Therefore, Resource Plan 1 is in effect. 

. From 6AM to QAM 

Windows will open because it has a higher priority than Windowl, so Resource 
Plan 3 is in effect. 

. From 9AM to 11AM 
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Even though Windowl was closed at 6AM because of a higher priorit\' window 
opening, at 'SAM, tliis higher priorit\' window is closed and Windowl still has two 
hours remaining on its original schedule. It will be reopened for these lemaining 
two hours and resource plan will be in effect. 

. From 11AM to 2PM 

A default resource plan is in effect because no windows are open. 
. From 2PM to 3PM 

Window2 will open so Resource Plan 2 is in effect, 

. From 3PM to 8PM 

Window4 is of the same priority as Window 2, so it will not interrupt Window2. 
Therefore, Resource Plan 2 is in effect. 

. From 8PM to 10PM 

Window4 will open so Resource Plan 4 is in effect. 
. From 10PM to 12AM 

A default resource plan is in effect because no windows are open. 

Figure 27-2 illustrates another example of how windows, resource plans, and 
priorities might be determined for a 24 hour schedule. 

Figure 27-2 Windows and Resource Plans (Examf^e 2) 
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In Figure 27—2, the follow^ing occurs: 

. From 12AM to 4AM 

A default resource plan is in effect. 

. From 4AM to 6AM 

Windowl has been assigned a low priority, but it opens because there are no high 
priority windows, so Resource Plan 1 is in effect. 

. From 6AM to 9AM 

Window3 will open because it has a higher priorit}' than Windowl. Note that 
Window6 does not open because another high priority window is iilready in 
effect. 
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From 9AM to 11AM 

At 9AM, WindowF or Windowl are the two possibilities. Tliev both liave low 
priorities, so the choice is made based on which has a greater percentage of its 
duration remaining. WindowS has a larger percentage of time remaining 
compared to the total duration than Windowl. Even if Windowl were to extend 
to, sav, 11:30AM, WindowS would have 2/3 * lOO"!] of its duration remaining, 
while Windowl would have only 2.5/7 * 100%, which is smaller. Thus. Resource 
Plan 5 will he in effect. 



Using Window Groups 



Window groups provide an easv way to schedule jobs that must run during multiple 
time periods throughout the dav, week, and so on. If vou create a window group, add 
windows to it, and then name this window group in a job's schedule_nai[ie 
attribute, the job runs during all the windows in the window group. 

Window groups reside in the SYS schema. This section introduces you to basic 
window group tasks, and discusses the following topics: 

Window Group Tasks and Their Procedures 

Creating Window Groups 

Dropping Window Groups 

Adding a Member to a Window Group 

Dropping a Member from a Window Group 

Enabling a Window Group 

Disabling a Window Group 

See Also: "Window Groups" on page 26-10 for an overview of 
window groups. 



Window Group Tasks and Their Procedures 

Table 27-6 illustrates common window group tasks and the procedures vou use to 
handle them. 



Table 27-6 Window Group Tasks and Their Procedures 



Task 



Procedure 



Privilege Needed 



Create a window group 

Drop a window group 

Add a member to a windotv group 

Drop a member to a window group 

Enable a window group 

Disable a window group 



CREATE_MINDO W_G HOOP 

DRO P_W I NDO W_GRO OP 

ADD_W I ND □W_G RODP_MEMBE R 

REMOVE_MIN"I)0 W_G RODP_MEMBER 

ENABLE 

DISABLE 



MAtilAGE SCHEDULER 
MANAGE SCHEDULER 
MflnAGE SCHEDULER 
MAtilAGE SCHEDULER 
MflnAGE SCHEDULER 
MANAGE SCHEDULER 



See "Scheduler Privileges " on page 28-30 for further information regarding privileges. 



Creating Window Groups 



You create a window group bv using the CREATE_WINDOW_GROUP procedure or 
Enterprise Manager, You can specify tlie member windows of the group when you 
create the group, or you can add them later using the ADD_WIwr)OM_GROUP_MEMBER 
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procedure. A window group cannot be a member of another window group. You can, 
however, create a window group that has no members. 

If vou create a window group and you specify a member window that does not exist, 
an error is generated and the window group is not created. If a window is already a 
member of a window group, it is not added again. 

Window groups are created in the SYS schema. Window groups, like windows, are 
created with access to PUBLIC, therefore, no privileges are required to access window 
groups. 

The following statement creates a window group called downtime and adds two 
windows (weeknights and weekends) to it: 

BEGIN 
DBMS_SCHEDULER.CEEA'FE_WINDOW_GR0UP { 

group_name => 'downtime', 

window_list => 'weeknights, weekends'); 
EHD; 
/ 

See Oracle Database PL/SQL Packages and Types Reference for detailed information about 
the GREAT E_WINDOW_GROUP procedure. 



Dropping Window Groups 



You drop one or more window groups by using the DR0P_WINDOW_GROUP procedure 
or Enterprise Manager This call will drop the window group but not the windows 
that are members of this window group. If you want to drop all the windows that are 
members of this group but not the window group itself, vou can use the 
DROP_WINDOW procedure and provide the name of the window group to the call. 

You can drop several window groups in one call by providing a com ma- delimited list 
of window group names to the DROP_WINDOW_GR0UP procedure call. For example, 
the following statement drops three window groups: 

BEGIH 

DBMS_SCHEDUI£R.DEOP_MINDOW_GRODP( ' windowgroupl , windowgroup2 , windowgroup3 ' ) ; 

EKD; 

/ 

See Oracle Database PL/SQL Packages and Types Reference for detailed information about 
adding and dropping window groups. 



Adding a Member to a Window Group 



You add windows to a window group by using the ADD_WIWDOW_GROUP_MEMBER 
procedure. 

You can add several members to a window group in one call, by specifying a 

com ma- delimited list of windows. For example, the following statement adds three 

windows to the window group window_groupl: 

BEGIN 

DBMS_SCHEDULER.ADD_WIWD01_GR0UP_MEMBER ( 'window_groupl ' , 

'windowl, window2 . window3 ' ] ; 
END; 
/ 
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If an alread\' open window is added to a window group, the Scheduler will not start 
jobs that point to this window group until the next window in the window group 
opens. 

See Orade Database PL/SQL Packages and Types Reference for detailed information about 
the ADD_WINDOW_GROUP_MEMBER procedure. 



Dropping a Member from a Window Group 



You can drop one or more windows from a window group by using the 
REMOVE_WINDOW_GROUP_MEMBER procedure or Enterprise Manager, Jobs with the 
stop_on_window_close flag set will only be stopped when a window closes. 
Dropping an open window from a window group has no impact on this. 

You can remove several members from a window group in one call bv specifying a 
comma-delimited list of windows. For example, the following statement drops three 
windows: 

BEGIH 

DBMS_3CHEDULER.REM0VE_WIMD0W_GR0UP_MEHBER('window_groupl' , 'windowl, window2 , 

window3 ' ] ; 
END; 
/ 

See Oracle Database PL/SQL Packages and Types Reference for detailed information about 
the REMOVE_WINDOW_GROUP_MEMBER procedure. 



Enabling a Window Group 



You enable one or more window groups using the ENABLE procedure or Enterprise 
Manager By default, window groups are created ENABLED. For example: 

BEGIH 

DBMS _3CIEDULEH. ENABLE [ ' sys .windowgroupl ' , ' sys .windowgroup2 , sys .windowgroup3 ' ) ; 

END; 

/ 

See Oracle Database PL/SQL Packages and Types Reference for detailed information about 
the ENABLE procedure. 



Disabling a Window Group 



You disable a window group using the DISABLE procedure or Enterprise Manager. 
This means that jobs with the window group as a schedule will not run even if the 
member windows open, however, the metadata of the window group is still there, so 
it can be reenabled. Note that the members of the window group will still open. 

You can also disable several window groups in one call by providing a 

com ma- delimited list of window group names to the DI SABLE procedure call. For 

example, the following statement disables three window groups: 

BEGIH 

DBMS_3CHEDU'LER. DISABLE ( ' sys .windowgroupl, sys .wiridowgroup2 , sys .windowgroup3 ' } ; 

END; 

/ 

Note that, in this example, the window group will be disabled, but the windows that 
are members of the window group will not be disabled. 
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See Oracle Database PL/SQL Packages and Types Refercno" for detailed information about 
the DISABLE procedure. 

Using Events 

TJie Scheduler works with two kinds of events: 

■ Events that the Scheduler raises to notify apphcations of a change in job state (for 
example, job complete) 

■ Events that applications raise to notify the Scheduler to start a job 

This section provides details on how to work with both kinds of events, and includes 
the foUowing topics: 

■ Using Events Raised bv the Scheduler 

■ Using Events Raised bv an Application 

See Also: 

■ "Events" on page 26-6 for an overview of Scheduler events 

■ "Examples of Creating Jobs and Schedules Based on Events" on 
page 28-28 

■ "Using Chains" on page 27-40 for information on how to use 
events with chains to achieve precise control over process flow 



Using Events Raised by the Scheduler 

You can set up a job so that the Scheduler raises an event when the job changes state. 
You do so bv setting the raiEe_eventE job attribute. Because vou cannot set this 
attribute with the CREATE_JOB procedure, vou must first create thejob and then alter 
the job with the SET_ATTRIBUTE procedure. 

By default, until you alter a job with SET_ATTRIBUTE, a job does not raise any state 
change events. 

Table 27-7 summarizes the one administration task involving events raised by the 
Scheduler. 

Table 27-7 Event Tasks and Their Procedures for Events Raised by the Scheduler 

Task Procedure Privilege Needed 

Altering a Job to Raise Events SET_ATTRIBUTE CREATE AMY JOB or ownersliip of job 

being altered or ALTER privileges on the 
job 

After vou enable job state change events for a job, the Scheduler raises these events by 
enqueuing messages onto the Scheduler event queue 

SYS . SCHEDULER$_EVENT_QUEUE. This queue is a secure queue, so depending on 
your apphcation, vou mav have to configure the queue to enable certain users to 
perform operations on it. See Oracle Streams Concepts and Adiiiinislratioir for 
information on secure queues. 

To prevent unlimited growth of the Scheduler event queue, events raised bv the 
Scheduler expire in 24 hours bv default (Expired events are deleted from the queue,) 
You can change this expiry time by setting the event_expirY_tiine Scheduler 
attribute with the SET_SCHEDULER_ATTRIBUTE procedure. See Oracle Database 
PL/SQL Packages and Types Reference for more information. 
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Altering a Job to Raise Events 

To enable job state change events for a job, you use the SET_ATTRIBUTE procedure to 
turn on bit flags in the rai3e_event3 job attribute. Each bit flag represents a 
different job state to raise an event for For example, turning on the least significant bit 
enables "job started" events to be raised. To enable multiple state change event types in 
one call, you add the desired bit flag values together and supplv the result as an 
argument to SET_AT TRIBUTE. 

The foUovifing example enables multiple state change events for job dw_reports. It 
enables the following event tvpes, both of which indicate some kind of error, 

■ JOB_FAILED 

■ JOB_SCH_LIM_REACHED 

BEGIH 

DBMS_3CHEDUI£R.SET_ATTRIBUTE( 'dw_reports ' , ' raise_eventE ' , 

DBMS_SCHEDULER . JOB_FAILED + DBMS_SCHEDULER. JOB_SCH_LIM_REACHED) ; 
END; 
/ 

See Also: The discussion of DBMS_SCHEDULER.SET_ATTRIBUTE in 
Oracle Database PL/SQL Packages and Types Reference for the names and 
values of job state bit flags 

Consuming Sclieduler-Raised Events witli your Application 

To consume Scheduler events, your application must subscribe to the Scheduler event 
queue SYS . SCHEDULERS_EVEHT_QUEUE, This queue is a secure queue and is owned 
by SYS. To create a subscription to this queue for a user, do the following: 

1. Log into the database as the SYS user or as a user with the MANAGE AHY QUEUE 
privilege. 

2. Subscribe to the queue using a new or existing agent. 

3. Run the package procedure DBMS_AQADM . ENABLE_DB_ACCESS as follows: 

DBMS_AQADM.ENABI£_DB_ACCESS{ageijt_iiarae, 6b_username) ; 

where a.gen t_name references the agent that vou used to subscribe to the events 
queue, and db_usern^!ne is the user for whom vou want to create a subscription. 

There is no need to grant dequeue privileges to the user. The dequeue privilege is 
granted on the Scheduler event queue to PUBLIC. 

As an alternative, the user can subscribe to the Scheduler event queue using the 
ADD_EVENT_QUEUE_SUBSCRIBER procedure, as shown in the following example: 

DBMS_3CHEDUI£R.RDD_EVENT_QnEUE_SUBSCRIBER(subscrii)er_jjarae) ; 

where subscriber_name is the name of the Oracle Streams Advanced Queuing 
(AQ) agent to be used to subscribe to the Scheduler event queue, (If it is NULL, an 
agent is created whose name is the user name of the calling user,) This call both creates 
a subscription to the Scheduler event queue and grants the user permission to dequeue 
using the designated agent. The subscription is rule-based. The rule permits the user 
to see onlv e\'ents raised by jobs that the user owns, and fUters out all other messages. 
After the subscription is in place, the user can either poll for messages at regular 
intervals or register with AQ for notification. 

See Oracle Streams Advanced Queuing User's Guide for more information. 
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Scheduler Event Queue 

The Scheduler event queue SYS . SCHEDULER$_EVENT_QUEUE is of type 
sched.ulej:$_event_inf o. The following are details on this type, 

create or replace type sys .sch.edulerS_event_inEo as object 



event_type 

obj ect_owner 

obj ect_iiaine 

eveiit_times tamp 

error_cod.e 

error_in3g 

event_stat"U3 

log_id 

run_coiin.t 

f a i 1 ur e_count 

retry_coijnt 

3 pare 1 

spare 2 

spare 3 

spare4 

spare 5 

spare 6 

spare? 

spares 



VAECHSE2 (4000J, 

VAECHSE2 (4000) , 

VAECHSE2 (4000) , 

TMESTMP WITH TIME ZONE, 

NUMBER, 

VAECHSE2 (4000) , 

NUMBER, 

NUMBER, 

NUMBER, 

NUMBER, 

NUMBER, 

NUMBER, 

NUMBER, 

VAECHSE2 (4000) , 

VAECHSE2 (4000) , 

TIMESTMP WITH TIME ZOME, 

TIMESTMP WITH TIME ZOHE, 

RM(2000), 

RM(2000), 



); 



Attribute 



Description 



event_type One of "JOB_STARTED", " JOB_SUCCEEDED", "JOB_FAILED", 

"JOB_BROKEH", "JOB_COMPLETED", "JOB_S TOPPED", 
"JOB_SCH_LIM_REACHED", " JOB_DISABLED", 
"JOB_CHAItT_STALLED", "JOB_0VER_MaX_DUR". 

For descriptions of these event types, see the Constants section for the 
DBMS_SCHEDULER package in Omck Database PL/SQL Packages and 
Tffpcs Reference. 

object_owner Owner of the job that raised the event 

object_name Name of the job that raised the event 

even t_tinie stamp Time at which the event occurred. 

error_code AppUcable only when an error is thrown during job execution. Contains 

the top-level error code. 

Applicable only when an error is thrown during job execution. Contains 
the entire error stack. 

Adds further qualification to the event type. If event_type is 

" JOB_STARTED," a status of 1 indicates that it is a normal start, and a 

status of 2 indicates that it is a retry. 

If event_type is "JOB_FAILED," a status of 4 indicates that it was a 
failure due to an error that was thrown during job execution, and a 
status of 8 indicates that it was an abnormal termination of some kind. 

If event_type is "JOB_STOPPED," a status of 16 indicates that it was a 
normal stop, and a status of 32 indicates that it was a stop with the 
FORCE option set to TRUE. 

Points to the ID in the scheduler job log from which additional 
information can be obtained. Note that there need not always be a log 
entry corresponding to an event. In such cases, log_id is NULL. 

Run count for the job when the event was raised. 



error_iiisg 



event status 



log_id 



run count 
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Attribute Description 



f ail"ure_count Failure count for the job when the event was raised. 

reti:y_caunt Retry count for the job when the event was raised. 

sparel - spare8 Currently not implemented 



Using Events Raised by an Appiication 



YoLir application can raise an event to notih' the Sclieduler to start a job. A job started 
Ln this way is referred to as an event-based job. The job can optionally retrieve the 
message content of the event. 

To create an event-based job, you must set these two additional attributes: 

■ queue_spec 

A queue specification that includes the name of the queue where vour application 
enqueues messages to raise job start events, or in the case of a secure queue, the 
queue name followed by a comma and the agent name. 

■ event_cond.ition 

A conditional expression based on message properties that must evaluate to TRUE 
for the message to start the job. The expression must have the syntax of an Oracle 
Streams Advanced Queuing rule. Accordinglv, vou can include user data 
properties in the expression, provided that the message payload is an object tj'pe, 
and that you prefix object attributes in the expression with tab.user_data. 

For more information on rules, see the DBMS_AQADM.ADD_SUBSCRIBER procedure 
in Oracle Database PL/SQL Packages and Types Reference. 

The following example sets event_cDnd.itiDn to select onlv card-swipe events 
that occur after midnight and before 9:00 a.m. Assume that the message payload is 
an object with h,vo attributes called event_type and event_tinie stamp, 

event_condition = ' taii.user_iiata.event_type = ' 'CAED_SMIPE' ' and 
extract hour from tab.user_data .event_timestaii!p < 9' 

You can specifv queus_Epec and event_condi tion as inline job attributes, or you 
can create an event schedule with these attributes and point to this schedule from the 
job. 

Note: The Scheduler runs the event-based job for each occurrence of 
an event that matches event_condition. However, events that 
occur while the job is already running are ignored; the event gets 
consumed, but does not trigger another run of the job. 



Table 27-8 describes common administration tasks involving events raised by an 
application (and consumed by the Scheduler) and the procedures associated with 
them. 
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Table 27-8 Event Tasks and Their Procedures for Events Raised by an Application 



Task 



Creating an Event-Based Job 
Altering an Event-Based Job 

Creating an Event Schedule 
Altering an Event Schedule 



Procedure 



CREATE_JOB 
SET ATTRIBUTE 



CREATE_EVEHT_S CHEDDLE 
SET ATTRIBUTE 



Privilege Needed 



CREATE JOB or CREATE MTi JOB 

CREATEANY JOB or ownership of the job 
being altered or ALTER privileges on the 

job 

CREATE JOB or CREATE AHY JOB 

CREATE AMY JOB or ownership of the 
schedule being altered or ALTER 
privileges on the schedule 



See Also: Oracle Streams Advanced Queuing User's Guide for 
information on how to create queues and enqueue messages. 

Creating an Event-Based Job 

You use the CREATE_JOB procedure or Enterprise Manager to create an event-based 
job. The job can include event information inline as job attributes or can specifv event 
information bv pointing to an event schedule. 

Like jobs based on time schedules, event-based jobs are not auto-dropped unless the 
job end date passes, max_runE is reached, or the maximum number of failures 
(max_f allures) is reached. 

Specifying Event Information as Jab Attributes To specify event information asjob 
attributes, you use an alternate svntax of CREATE_JOB that includes the queue_spec 

and event_cond.ition attributes. 

The following example creates a job that starts whenever someone swipes a badge to 
enter a data center: 



'nryjob' , 

'nryjirograiii' , 

' tab. user_data.event_ type = ' ' CAHD_SWIPE ' ' 

' entrY_events_q , entrY_agentl ' , 

TRUE, 

'Start job when someoQe syipes a badge'); 



BEGIN 




DBMS_SCHEDULER . CREATE. 


_JOB 


j ob_name 


=> 


pr ogr am_naine 


=> 


event_condltion 


=> 


ijueue_spec 


=> 


enabled 


=> 


comments 


=> 


EKP; 




/ 





See Oracle Database PL/SQL Packages and Types Reference for more information 
regarding the CREATE_JOB procedure. 

Specifying Event Information in an Event Schedule To specify event information with an 
event schedule, you set the job's schedule_name attribute to the name of an event 
schedule, as shown in the following example: 

BEGIN 

DBMS SCHEDITI^R. CREATE JOB ( 



j ob_name 


=> 


'mV—job' , 


progr am_naine 


=> 


' my jirogram ' , 


schedule name 


=> 


' entrY_event3_schedule ' , 


enabled 


=> 


TRUE, 


comments 


=> 


'Start job when someone swipes a badge'); 


END; 







Scheduling Jobs with Oracle Scheduler 27-37 



Using Events 



/ 

See "Creating an Event Schedule" on page 27-38 for more information. 

Altering an Event-Based Job 

You alter an event-based job bv using the SET_ATTRIBUTE procedure. For jobs that 
specify the event inline, you cannot set the queue_spec and event_condition 
attributes individually with SET_ATTRIBUTE. Instead, you must set an attribute 
called event_3pec, and pass an event condition and queue specification as the third 
and fourth arguments, respectively, to SET_ATTRIBUTE. 

The following is an example of using the event_spec attribute: 

BEGIH 

DfflS_SCHEDiri£R.SET_aTTRIBnTE ['iny_job', ' event_spec ' , 

' tab."ussr_data . eventjype = ' 'BfiD_BM)GE' ' ' , 'entry_events_g, entry_ageiitl ' } ; 
END; 
/ 

See Oracle Database PL/SQL Packages and Types Reference for more information 
regarding the SET_ATTRIBUTE procedure. 

Creating an Event Schedule 

You can create a schedule that is based on an event. You can then reuse the schedule 
for multiple jobs. To do so, use the GREAT E_EVEISIT_SCHEDULE procedure, or use 
Enterprise Manager The following is an example of creating an event schedule: 

BEGIH 
DBMS_SCHEDUI£R.CEEATE_EVENT_SCHEDULE ( 

schedule_nanie => ' entry_events_schedule ' , 

start_date => SYSTMESTMP, 

event_conditioii => ' tab.user_data .event_type = ' 'CARD_SWIPE' ' ', 

queue_spec => ' entry_events_q, eiitry_agentl ' ) ; 

END; 
/ 

You can drop an event schedule using the DEOP_SCHEDULE procedure. See Oracle 
Database PL/SQL Packages and Types Reference for more information on 

CREATE_EVEWT_SCHEDULE. 

Altering an Event Schedule 

You alter the event information in an event schedule in the same wav that vou alter 
event information in a job. For more information, see "Altering an Event-Based job" on 
page 27-38. 

The following example demonstrates how to use the SET_ATTRIBUTE procedure and 
the event_Epec attribute to alter event information in an event schedule. 

BEGIH 

DEMS_3CHEDiri£R.SET_aTTRIBnTE [ ' eritry_events_Echedule ' , ' event_spec ' , 

' tal]."user_data . event_type = ' 'BflD_BADGE' ' ' , 'entry_events_q, entry_agentl ' } ; 
END; 
/ 

See Oracle Database PL/SQL Packages and Types Reference for more information 
regarding the SET_ATTRIBUTE procedure. 
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Passing Event Messages into an Event-Based Job 

Through a metadata argument, the Scheduler can pass to an event-based job the 
message content of the event that started the job. The following rules apply: 

■ The job must use a named program of t}'pe STOEED_PROCEDURE, 

■ One of the named program's arguments must be a metadata argument with 

metadata_attribute set to EVENT_MESSAGE. 

■ The stored procedure that implements the program must have an argument at the 
position corresponding to the named program's metadata argument. The 
argument type must be the data tvpe of the queue where your application queues 
the job- start event. 

If you use the RUH_JOB procedure to manually run a job that has an EVENT_MESSAGE 
metadata argument, the value passed to that argument is NULL. 

The foilow^ing example shows how^ to construct an event-based job that can receive the 
event message content: 

create or replace procedure my_stored_proc (event_inEg IN event_queue_type} 

as 

begin 

-- retrieve and process message body 

-- do other work 
end; 
/ 

begin 

dbins_scheduler . create_program [ 
prograi[\_name => 'iny_prog', 
prograi[\_action=> 'my_stored_proc ' , 
program_type => ' STORED_PEOCEDURE' , 
number _of_arguinents => 1, 
enabled => FALSE) ; 

dbms_sched"uler .deEirie_metadata_arguinent { 
program_riame => 'my_prog', 
argunient_position => 1 , 
metadata_attribute => 'EVENT_MESSAGE' } ; 

dbins_sched"uler .enable ( 'my_prog' ) ; 
exception 

when others then raise ; 
end ; 
/ 

begin 

dbins_sched"uler .create__job ( 

j ob_name = > ' my_evt_j ob ' , 

program_naine => 'my_prog', 

schedule_name => 'my_evt_sch' , 

enabled => true, 

auto_Drop => false) ; 
exception 

when others then raise ; 
end ; 
/ 
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Using Chains 



A chain is a named series of programs that are linked togetlier for a combined 
objective. To create and use a chain, you complete these steps in order: 



Step 




See... 




1. Create a chain object 




Creating Chains 




2. Define the steps in the chain 




Defining Chain Steps 




3. Add rules 




Adding Rules to a Chain 




4. Enable the chain 




Enabhng Chains 




5. Create a job that points to the 


chain 


Creating Jobs for Chains 





Other topics discussed in this section include; 
Chain Tasks and Their Procedures 
Dropping Chains 
Running Chains 
Dropping Rules from a Chain 
Disabling Chains 
Dropping Chain Steps 
Altering Chain Steps 
Handling Stalled Chains 

See Also: 

■ "Chains" on page 26-7 for an overview of chains 

■ "Examples of Creating Chains" on page 28-27 



Chain Tasks and Their Procedures 



Table 27—9 illustrates common tasks involving chains and the procedures associated 
with them. 



Table 27-9 Chain Tasks and Their Procedures 



Task 



Procedure 



Privilege Needed 



Create a chain 

Drop a chain 

Aiter a chain 
Aiter a chain 
Aiter a running chain 
Run a chain 



CREATE CHAIB 



DROP CHAin 



ALTER CHAIN 



SET ATTRIBUTE 



CREATE JOB, CREATE EVflLUATIOM CONTEXT and CREATE ROLE 
SET if the owner. CREATE AHY JOB, CREATE ANY RULE SET and 
CREATE ANY EVALDATIQN CONTEXT othen\'l5e 

Ownership of the chain or ALTER privileges on tlie cliain or CREATE 
ANY lJOB privileges. If not owner, also requires DROP ANY 

EVALUATION CONTEXT and DROP ANY RULE SET 

Ownership of the chain, or ALTER privileges on the chain or CREATE 

ANY JOB 

Ownership of the chain, or ALTER privileges on tiie cliain or CREATE 

ANY JOB 



ALTER_RUNNING_CHAIN Ownership of the job, or ALTER piiv i leges on the job or CREATE ANY 

JOB 



HUN CHAIN 



CREATE JOB or CREATE ANY JOB. Li addiboR, the owner of tile new 
job must have EXECUTE pri\ ileges on the chain or EXECUTE ANY 

PROGRAI-1 
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Table 27-9 (Cont.) Chain Tasks and Their Procedures 



Task 



Procedure 



Privilege Needed 



Add rules to a chain 

Alter rirles in j chdin 

Drop rules from a chain 
Enable a chain 
Disable a clidin 
Create steps 
Drop steps 
Alter steps 



DEFIHE CHAIB RULE 



DEFINE CHAIN RULE 



DROP CHAIN RULE 



DISABLE 



DEFINE CHAIN STEP 



DROP CHAIN STEP 



DEFINE CHAIN STEP 



Ownership of the chain, or ALTER privileges on the chain or CREATE 
ANY JOB privileges. CREATE RULE if the owner of the chain, CREATE 
ANY RULE otherwise 

Ownership of the chain, or ALTER privileges on tlie chain or CREATE 
ANY JOB privileges. If not owner of the ch-iin, requires ALTER 
privileges on the rule or ALTER ANY RULE 

Ownership of the chain, or ALTER privileges on tlie chain or CREATE 
ANY JOB privileges. DROP AMY RULE if not the owner of the chain 

Ownership of the chain, or ALTER privileges on tlie chain or CREATE 

ANY JOB 

Ownership of the chain, or ALTER privileges on tlie chain or CREATE 

ANY JOB 

Ownership of the chain, or ALTER privileges on tlie chain or CREATE 

AMY JOB 

Ownership of the chain, or ALTER privileges on tlie chain or CREATE 

ANY JOB 

Ownership of the chain, or ALTER privileges on the chain or CREATE 

ANY JOB 



Creating Chains 



You create a chain bv using the CREATE_CHAIN procedure. After creating the chain 
object with CREATE_CHAIN, you define chain steps and chain rules separately. 

The rule_Eet_name and evaluation_interval arguments are normally left 
NULL. evaluation_interval can define the times that chain rules get evaluated, 
other than when the job starts or a step completes. rule_set_name is for advanced 
users only. 

See Oracle Database PL/SQL Packages and Types Reference for more information on 

CREATE_CHAIN. 

The followring is an example of creating a chain: 

BEGIN 

DBMS_SCHEDULER.CREATE_CHAIN ( 

chain_name => 'my_chainl ' , 

r"ule_set_iiaiiie => HULL, 

evaluationjnterval => NULL, 

comments => 'My first chain'); 

END; 
/ 



Defining Chain Steps 



After creating a chain object, you define one or more chain steps. Each step can point 
to one of the following: 

■ A program 

■ Another chain (a nested chain) 

■ An event 

You define a step that points to a program or nested chain by using the 
DEFINE_CHAIN_STEP procedure. An example is the following, which adds two steps 

to mY_chainl: 
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BEGIH 

DBMS_3CHEDULER.DEFIHE_CHAIN_STEP ( 
chain_naine => 'iny_chainl ' , 

step_naiiie => 'ir[y_stepl ' , 

progranLname => ' iny_pragraiiil ' 

DBMS SCHEDULER. DEFIHE CHAIN STEP ( 





chain_iiaiiie 


=> 


'irry_ 


_chainl 




step_naiiie 


=> 


'my_ 


.step 2 ' 




program_name 


=> 


'irry_ 


_chain2 


END; 
/ 









To define a step that wails for an event to occur, yon use the 

DEFINE_CHAIW_EVEWT_STEP procedure. Procedure arguments can point to an event 
schedule or can include an inline queue specification and event condition. This 
example creates a third chain step that waits for the event specified in the named event 
schedule: 

BEGIH 
DBMS_SCHEDULER.DEFIHE_CHAIN_EVENT_STEP ( 

chainjiame => 'my_chainl ' , 

step_naiiie => 'my_step3', 

event_sched.ule_naine => 'iiry_event_sched"ule' ) ; 
END; 
/ 

See Oracle Database PL/SQL Packages and Types Reference for more information 
regarding the DEFINE_CHAIN_STEP and DEFINE_CHAIN_EVENT_STEP procedures. 



Adding Rules to a Chain 



Chain rules define when steps run, and define dependencies between steps. Each rule 
has a condition and an action. If the condition evaluates to TRUE, the action is 
performed. The condition can contain Scheduler chain condition syntax or any syntax 
that is valid in a SQL WHERE clause. The syntax can include references to attributes of 
am' chain step, including step completion status. A t}'pical action is to run a specified 
step. 

Conditions are usually based on the outcome of one or more previous steps. For 
example, vou might want one step to run if the two previous steps succeeded, and 
another to run if either of the b,vo previous steps failed. 

All rules added to a chain work together to define the overall behavior of the chain. 
When the job starts and at the end of each step, all rules are evaluated to see what 
action or actions occur next (You can cause rules to be evaluated at regular inter\'als 
also. See "Creating Chains" on page 27-il for details,) 

You add a rule to a chain with the DEFINE_CHAIN_RULE procedure. You call this 
procedure once for each rule that you want to add to the chain. 

Starting the Chain 

At least one rule must have a condition that always evaluates to TRUE so that the chain 
can start when the job starts. The easiest wav to accomplish this is to just set the 
condition to TRUE' if you are using Schedule chain condition syntax, or 'l= l' if you 
are using SQL svntax. 
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Ending the Chain 

At least one chain rule must contain an action of 'END'. A chain job does not 
complete until one of the rules containing the END action evaluates to TRUE. Several 
different rules with different END actions are common, some with error codes, and 
some without. 

If a chain has no more running steps or it is not waiting for an e\'ent to occur, and no 
rules containing the END action evaluate to TRUE (or there are no rules with the END 
action), the job enters the CHAIW_STALLED state. See "HandUng Stalled Chains" on 
page 27-47 for more information. 

Example 

The following example defines a rule that starts the chain at step 1 and a rule that 
starts step 2 when step 1 completes, rule_nai[ie and comments iire optioniil and 
default to NULL. 

BEGIN 

DBMS SCHEaJULER. DEFINE CHAIN RULE ( 





chain_iiaiiie 


=> 


' my_cha inl ' , 




condition 


=> 


' TRUE ' , 




action 


=> 


'START stepl' , 




rule_naiiie 


=> 


'my_rulel ' , 




comments 


=> 


'start the chain') 


DBMS_SCHEDULER. 


.DEFINE 


_CHAIN_RULE ( 




chainjiame 


=> 


' my_cha inl ' , 




condition 


=> 


'stepl completed'. 




action 


=> 


'START step2'. 




nile_nanie 


=> 


'my_rule2 ' ) ; 


END; 








See Also: 





Oracle Database PL/SQL Packages and Types Reference for 
information on the DEFINE_CHAIN_RULE procedure and on 
Scheduler chain condition syntax. 

"Examples of Creating Chains" on page 28-27 



Enabling Chains 



You enable a chain with the ENABLE procedure, A chain must be enabled before it can 
be run by a job. Enabling an already enabled chain does not return an error 

The following example enables chain mY_chainl: 

BEGIN 

DBMS_SCHEDULER. ENABLE ( 'irry_chainl ' ) ; 

END; 

/ 

See Oracle Database PL/SQL Packages and Types Referena for more information 
regarding the ENABLE procedure. 
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Note: Chains are automatically disabled by the Scheduler when: 

■ The program that one of the chain steps points to is dropped 

■ The nested chain that one of the chain steps points to is dropped 

■ The event schedule that one of the chain event steps points to is 
dropped 



Creating Jobs for Chains 



To run a chain, vou must either use the RUW_CHAIW procedure or create a job of t\'pe 
'chain'. The job action must refer to the chain name, as shown in the following 
example: 

BEGIH 
DfflS_SCHEDULER.CREATE_JOB ( 

j ob_naine => ' chain_j ob_l ' , 

job_type => 'CHAIN', 

j ob_action => ' my_chainl ' , 

repeat_interval => ' freq=dailY;byho"ur=13;byminute=0;bysecond=0 ' , 

enabled => TRUE) ; 
END; 
/ 

For ever}' step of a chain job that is running, the Scheduler creates a step job with the 
same job name and owner as the chain job. Each step job additionally has a job 
subname to uniqiielv identify it The job siibname is included as a column in the views 

*_SCHEDULER_RUNNIWG_JOBS, '■_SCHEDULER_JOB_LOG, and 

*_SCHEDULER_JOB_RUN_DETAILS. The job subname is normally the same as the 
step name except in the following cases: 

■ For nested chains, the current step name mav have already been used as a job 
subname. In this case, the Scheduler appends '_1^ to the step name, where N is an 
integer that results in a unique job subname. 

■ If there is a failure when creating a step job. the Scheduler logs a FAILED entrv in 
the job log views (*_SCHEDULER_JOB_LOG and 
■'_SCHEDULER_JOB_RUW_DETAILS) with the job subname set to 'step_iiame_0'. 

See Also: 

■ Omcic Database PL/SQL Packages and T^pes Reference for more 
information on the CREATEJOB procedure. 

■ "Running Chains" on page 27-45 for another way to run a chain 
without creating a job ahead of time. 



Dropping Cliains 



You drop a chain, including its steps and rules, by using the DROP_CHAIN procedure. 
An example of dropping a chain is the following, which drops my_chainl: 



BEGIH 

DBMS_SCHEDtJLER.DROP_CHA[H ( 
chain_name => 'my_chainl ' 
force => TRUE) ; 

END; 

/ 
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See Orach Database PL/SQL Packages and Types Reference for more information 
regarding the DROP_CHAIW procedure. 



Running Chains 



You can use the RUN_CHAIN procedure to run a chain immediatelv, without having to 
create a job ahead of time for the chain. You can also use RUN_CHAIN to run ordy part 
of a chain, 

RUN_CHAIN creates a temporary job to run the specified chain. If you supply a job 
name, the job is created with that name, otherwise a default job name is assigned. 

If you supply a list of start steps, onlv those steps are started when the chain begins 
running. (Steps that would normally have started do not run if they are not in the list.) 
If no list of start steps is given, the chain starts normally — that is, an initial evaluation 
is done to see which steps to start running. An example is the following, which 
immediately runs the chain niY_chainl: 

BEGIN 

DBMS_SCHED0I£R.R™_CHAIM [ 

chain_naine => 'my_chairil ' , 

job_name => 'quick:_ch.airi_job ' , 

start_3tep3 => 'n^_stepl, my_step2 ' ) ; 
EHD; 
/ 

See Oracle Database PL/SQL Packages and Types Reference for more information 
regarding the RUW_CHAIN procedure. 



Dropping Ruies from a Chain 



You drop a rule from a chain by using the DROP_CHAIW_RULE procedure. An example 
is the following, which drops mY_rulel: 

BEGIN 

DBMS_SCHEDUI£R.DEOP_CHAIN_RULE { 

chain_naine => 'my_chainl', 

r"ule_naiiie => 'my_rulel', 

force => TRUE) ; 

END; 
/ 

See Orack Database PL/SQL Packages and Types Reference for more information 
regarding the DROP_CHAIW_RULE procedure. 



Disabling Cliains 



You disable a chain bv using the DISABLE procedure. An example is the following, 
which disables mY_chainl: 

BEGIN 

DBMS_3CHEDULER. DISABLE { ■my_chainl ' ) ; 

END; 

/ 

See Orach Database PL/SQL Packages and Types Reference for more information 
regarding the DI SABLE procedure. 
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Note: Chains are automatically disabled by the Scheduler when: 

■ The program that one of the chain steps points to is dropped 

■ The nested chain that one of the chain steps points to is dropped 

■ The event schedule that one of the chain event steps points to is 
dropped 



Dropping Chain Steps 



You drop a step from a chain by using the DROP_CHAIN_STEP procedure. An 
example is the following, which drops mY_3 tep2 from mY_chain2: 

BEGIN 

DBMS_SCHEDUI£R.DEOP_CHftIN_STEP ( 

chain_name => 'iny_chain2 ' , 

stepjiame => 'my_Etep2', 

force => TRUE) ; 

END; 
/ 

See Orach Database PL/SQL Packages and Types Reference for more information 
regarding the DROP_CHAIN_STEP procedure. 



Altering Chain Steps 



You alter the SKIP, PAUSE, or RESTART_ON_RECOVERY attributes of a chain step by 
using the ALTER_CHAIN procedure. An example is the following, which causes 
mY_step3 to be skipped; 



BEGIH 






DBMS 3CHEDUI£. 


.ALTER_CHAIN ( 


chain_name 


=> 


' iiiy_chaiiil ' , 


3tep_naiiie 


=> 


' iiiy_s tep3 ' , 


attribute 


=> 


'SKIP', 


value 


=> 


TRUE) ; 


END; 
/ 







The ALTER_CHAIN procedure affects onlv future runs of the specified steps. 

You alter the steps in a running chain by using the ALTER_RUNNING_CHAIN 
procedure. An example is the following, which causes step niY_s tepl to pause after it 
has completed — that is, its state is changed to PAUSED and its completed attribute 
remains FALSE: 



BEGIH 






DBMS SCHEDULER 


.ALTER 


RGNNIHG CHAIH 


j ob_naiiLe 


=> 


'my_jobl ' , 


3tep_naiiie 


=> 


'my_Etepl ' , 


attribute 


=> 


' PAUSE ' , 


value 


=> 


TRUE) ; 


END; 
/ 







The ALTER_RUNNING_CHAIN procedure affects only the running instance of the 
chain. 
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See Oracle Database PL/SQL Packages and Types Rcferciia for more information 
regarding the ALTER_CHAIW procedure. 

Handling Stalled Chains 

A chain can become stalled when no steps are running, no steps are scheduled to run, 
no event steps are waiting for an event, and the evaluation_interval for the chain is 
NULL. The chain can make no further progress unless vou manually intervene. In this 
case, the state of the job that is running the chain is set to CHAIN_STALLED. (However, 
the job is still hsted in the '_SCHEDULER_RUNNING_JOBS views.) 

You can troubleshoot a stalled chain with the views 

ALL_SCHEDULEH_HUNNING_CHAINS, which shows the state of all steps in the chain 
(including any nested chains), and ALL_SCHEDULER_CHAIN_RULES, which contains 
all the chain rules. 

You can enable the chain to continue by altering the state of one of its steps with the 
ALTER_RUNNING_CHAIN procedure. For example, if step 11 is waiting for step 9 to 
succeed before it can start, and if it makes sense to do so, vou can set the s ta.te of step 

9 to 'SUCCEEDED'. 

Alternatively, if one or more rules are incorrect, yoti can use the 

DEFINE_CHAIN_RULE procedure to replace them (using the same rule names), or to 
create new rules. The new and updated rules apply to the running chain and all future 
chain runs. After adding or updating rules, you must run 
EVALUATE_RUNNING_CHAIN on the stalled chain job to trigger any required actions. 

Allocating Resources Among Jobs 

It is not practical to manage resource allocation at an individual job level, therefore, 
the Scheduler uses the concept of job classes to manage resource allocation among 
jobs. In addition to job classes, the Scheduler uses the Resource Manager to manage 
resource allocation among jobs. 

Allocating Resources Among Jobs Using Resource Manager 

The Database Resource Manager controls how resources are allocated among database 
sessions. It not only controls asynchronous sessions like jobs but also synchronous 
sessions hke user sessions. It groups all "units of work ' in the database into resource 
consumer groups and uses a resource plan to specify how the resources are allocated 
among the various groups. See Chapter 25, 'Managing Resource Allocation with 
Oracle Database Resource Manager" for more information about what resources are 
controlled bv the Resource Manager 

For jobs, resource allocation is specified by associating a job class with a consumer 
group, or by associating a job class with a database service name and mapping that 
database service to a consumer group. The consumer group that a job class maps to 
can be specified when creating a job class. If no resource consumer group or database 
service name is specified when a job class is created, the job class maps to the default 
consumer group. If both the resource_consumer_group and service attributes of 
a job class are set, and tlie designated service maps to a resource consumer group, the 
resource consumer group named in the resource_consumei:_group attribute takes 
precedence. 

The Scheduler tries to limit the number of jobs that are running simultaneously so that 
at least some jobs can complete, rather than running a lot of jobs concurrently but 
without enough resources for anv of them to complete. 
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The Scheduler and the Resource Manager are tightiv integrated. The job coordinator 
obtains database resource availability from the Resource Manager. Based on that 
information, the coordinator determines how many jobs to start. It wilt only start jobs 
from those job classes that will have enough resources to run. The coordinator will 
keep starting jobs in a particular job class that maps to a consumer group until the 
Resource Manager determines that the maximum resource allocated for that consumer 
group has been reached. This means that it is possible that there will be jobs in the job 
table that are ready to run but will not be picked up bv the job coordinator because 
there are no resources to run them. Therefore, there is no guarantee that a job will run 
at the exact time that it was scheduled. The coordinator picks up jobs from the job 
table on the basis of which consumer groups still have resources available. 

Even when jobs are running, the Resource Manager will continue to manage the 
resources that are assigned to each running job based on the specified resource plan. 
Keep in mind that the Resource Manager can only manage database processes. The 
active management of resources does not appiv to external jobs. 

In a database, only one resource plan can be in effect at one time. It is possible to 
manually switch the resource plan that is active on a system using the 
DBMS_RESOUECE_MAWAGEE . SWITCH_PLAW procedure. In special scenarios, you 
might want to run a specific resource plan and disable resource plan switches caused 
by windows opening. To do this, vou can use the 

DBMS_RESOURCE_MAWAGER . SWITCH_PLAW procedure with 

allow_scheduler_plan_s witches set to FALSE, Also remember that a Scheduler 
window can have a resource plan attribute. The designated resource plan remains 
active while the window is open. 



Example of Resource Allocation for Jobs 



The following example can help to understand how resources are allocated for jobs. 
Assume that the active resource plan is called "Night Plan" and that there are three job 
classes: JCl, which maps to consumer group DW; JC2, which maps to consumer group 
OLTP; and JC3, which maps to the default consumer group. Figure 27-3 offers a 
simple graphical illustration of this scenario. 

Figure 27-3 Sample Resource Plan 



DW 

Consumer 

Group 



Nighl 
Plan 



60%^r 30% ^^10' 



OLTP 

Consumer 

Group 



Other 

Consumer 

Group 



This resource plan clearly gives priority to jobs that are part of job class JCl, 
Consumer group DW gets 60''u of the resources, thus jobs that belong to job class JCl 
will get 60''u of the resources. Consumer group OLTP has 30°u of the resources, which 
implies that jobs in job class JC2 will get 30"o of the resources. The consumer group 
Other specifies that all other consumer groups will be getting ICu of the resources. 
This means that all jobs that belong in job class JC3 will share 10°u of the resources 
and can get a maximum of ICu of the resources. 

Note that resources that remain unused by one consumer group are available from use 
by the other consumer groups. So if the jobs in job class [CI do not fully use the 
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allocated 60%, the unused portion is available for use bv jobs in classes IC2 and JC3. 
Note also that the Resource Manager does not begin to restrict resource usage at all 
until CPU usage reaches 100%, See Chapter 25, "Managing Resource Allocation with 
Oracle Database Resource Manager" for more information. 



Scheduling Jobs with Oracle Scheduler 27-49 



Allocating Resources Among Jobs 



27-50 Oracle Database Administrator's Guide 



28 
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In this chapter: 

Configuring Oracle Scheduler 
Monitoring and Managing the Scheduler 
Enabling and Disabling Remote External Jobs 
Import/Export and the Scheduler 
Troubleshooting the Scheduler 
Examples of Using the Scheduler 
Scheduler Reference 



Note: This chapter discusses the use of the Oracle-supphed 
DBMS_SCHEDULER package to administer scheduling capabilities. 
See the Oracle Dalahast' PL/SQL Packages and Types Refeivtrcc for 
DBMS_SCHEDULER syntax. An easier way to administer the 
Scheduler is with the graphical interface of Oracle Enterprise 
Manager. 

To administer the Scheduler with Enterprise Manager: 

1. Access the Database Home page. 

See Omck' Dahibnii' 2 Dai/ DBA tor instructions. 

2. At the top of the page, click to display the Server property p^ige. 

3. Locate the Oracle Scheduler section on the page, and then click the 
desired link. 

Configuring Oracle Sclieduler 

The following tasks are necessary when configuring Oracle Scheduler (the Scheduler): 

■ Task 1: Setting Scheduler Privileges 

■ Task 2: Configuring the Scheduler Environment 

Task 1: Setting Scheduler Privileges 

You should have the SCHEDULER_ADMIN role to administer the Scheduler. Typically, 
database administrators will already have this role with the ADMIN option as part of 
the DBA (or equivalent) role. You can grant this role to another administrator bv 
issuing the following statement: 

GRANT ECHEDOLER_ADMIM TO UEernams; 
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Beciiuse the SCHEDULER_ADMIISI role is a powerful role allowing a grantee to execute 
code as any user, vou should consider granting individual Scheduler system privileges 
instead. Object and system privileges are granted using regular SQL grant syntax. An 
example is if the database administrator issues the following statement: 

GRANT CREATE JOB TO scott; 

After this statement is executed, scott can create jobs, schedules, or programs in his 
schema. Another example is if the database administrator issues the following 
statement; 

GRAHT MMAGE SCHEDULER TO adam; 

After this statement is executed, adam can create, alter, or drop window^s, job classes, 
or window groups. He will also be able to set and retrieve Scheduler attributes and 
purge Scheduler logs. 

Setting Chain Privileges 

Scheduler chains use underlying Oracle Streams Rules Engine objects along with their 
associated privileges. To create a chain in his own schema, a user must have the 
CREATE JOB privilege in addition to the Rules Engine privileges required to create 
rules, rule sets, and evaluation contexts in his own schema. These can be granted by 
issuing the following statement: 

BEGIH 

DfflS_RULE_ADM,GRaMT_3YSTEM_PRIVILEGE(DBMS_RULE_ADH,CREATE_RDLE_0BJ, 'usemame' ) , 

DfflS_RULE_ADM , GRaMT_3YSTEM_PHIVILEGE ( 

DBMS_EULE_ADM , CREATE_RtrLE_SET_OB J , ' us emame ' ) , 
DBMS_RUI£_ADM , GRaHT_3YSTEM_PRIVILEGE ( 

DfflS_RULE_ADM , CREATE_EVALUATION_CONTEXT_OBJ, ' usernanie ' } 
END; 
/ 

To create a chain in a different schema, a user must have the CREATE ANY JOB 
privilege in addition to the privileges required to create rules, rule sets, and evaluation 
contexts in schemas other than his own. These can be granted by issuing the following 
statement: 

BEGIH 

DfflS_RULE_ADM , GRAHT_SYSTEM_PRIVILEGE ( DBM3_RULE_ADM , CREATE_AHY_RUI£ , ' us ername ' ) , 

DfflS_RULE_ADM , GRaMT_3YSTEM_PHIVILEGE ( 

DBMS_RULE_ADM , CREATE_AMY_RtJLE_SET , ' us emame ' ) , 
DfflS_RUI£_ADM , GRaMT_3YSTEM_PHIVILEGE ( 

DfflS_RULE_ADM , CREATE_AHY_EVALtIATION_CONTEXT, ' usernanie ' } 
END; 
/ 

Altering or dropping chains in schemas other than the user's schema will require 
corresponding svstem Rules Engine privileges for rules, rule sets, and evaluation 
contexts. See the usage notes for DBMS_RULE_ADM . GRAWT_OBJECT_PRIVILEGE for 
more information on Streams Rules Engine privileges. 

See Also: 

■ "Scheduler Privileges" on page 28-30 

■ "Chain Tasks and Their Procedures" on page 27-40 for more 
information regarding chain privileges. 
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Task 2: Configuring the Scheduier Environment 

This section discusses the following tasks: 

Task 2A: Creating Job Classes 
Task 2B: Creating Windows 
Task 2C: Creating Resource Plans 
Task 2D: Creating Window Groups 
Task 2E: Setting Scheduler Attributes 



Task 2A: Creating Job Classes 

To create job classes, use the CREATE_JOB_CLASS procedure. The following statement 
illustmtes an exiimple of creating a job class: 

BEGIH 

EEMS_SCHEDOLER.CHEATE_J0B_CIASS [ 

j Db_class_naine => 'myjobclassl ' , 

resource_conH"uiiLei:_group => 'iny_res_groupl ' , 

CDirnientE => 'This is irry first job class.'); 

EHD; 

/ 

This statement creates a job class called mY_jobclas si with attributes such as a 
resource consumer group of mY_res_groupl. To verify the job class contents, issue 
the following statement: 



SELECT ' FROM DBA_SCHEDULER_JOB_CLftSSES ; 



J0B_CIA5S_MME 


RESODHCE_COHSU 


SERVICE 


LOGGING_LEV 
RUHS 


LOG_ 


.HISTORY 


COMMENTS 


DEFAULT JOB CLASS 








The default 


A"nT0_TA5KS_J0B_CLASS 


ADT0_TA3K_CON 








RUHS 






System maintenance 


FINMCE_JOBS 


FIHfiNCE_GEODP 








RUMS 








MY JOBCLASSl 


MY RES GROUPl 








RUI3 






My first job class 


MY_CLASS1 




iiry_ 


_servicel 


RUIS 






My second job clas 


5 rows selected. 



















Note that job classes are created in the SYS schema. 

See Also: Oracle Database PL/SQL Packages and Types Reference for 
CREATE_JOB_CLASS syntax, "Creating Job Classes" on page 27-22 
for further information on job classes, and "Examples of Creating 
Job Classes" on page 28-21 for more examples of creating job classes 



Task 2B: Creating Windows 

To create windows, use the CREATE_WINDOW procedure. The following statement 
illustrates an example of creating a window: 

BEGIN 

DBMS SCHEDULER. CREATE WINDOW ( 



window_name => 

resource_plan => 
start_date => 

repeat_interval => 
end_date => 

duration => 



my_windowl ' , 
my_resourceplanl ' , 

15-APR-03 01.00.00 AM Europe/Lisbon' 
FREQ=DAILY ' , 

15-SEP-04 01.00.00 AM Europe/Lisbon' 
interval '50' minute, 
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window_priority => 'HIGH', 

comments => 'This is my first window.']; 

END; 
/ 

To verify that the window was created properly, query the view 
DBA_SCHEDULER_WINDOWS. As an example, issue the following statement: 

SELECT WIHDOW_HfflE, KESOURCEJLAK, DURATIOH, REPEAT_IHTERVAL 
EROM DBA_3CHEDUIZR_WIND0MS ; 

WINDOM_HME RESOURCE_PLM DURATIOH REPEATJHTERVAL 

MY_WIND0W1 MY"_RES0URCEPLAH1 +000 00:50: 00 FREQ=DAILY 



See Also: Oracle Database PL/SQL Packages and Types Reference for 
CHEATE_WI]srDOW syntax, "Creating Windows" on page 27-23 for 
further information on windows, and "Examples of Creating 
Windows" on page 28-22 for more examples of creating job classes 

Task 2C: Creating Resource Plans 

To create resource plans, use the CREATE_SIMPLE_PLAN procedure. This procedure 
enables vou to create consumer groups and allocate resources to them by executing a 
single statement. 

The foUowing statement illustrates an example of using this procedure to create a 
resource plan called mY_simple_planl: 

BEGIN 

DBMS_RESOURCE_MANAGER.CREATE_SIMPLE_PLM ( 

simple__pla.n => 'my_siniple_planl ' , 

consuraer__groupl => 'my_gro"upl ' , 

groijpl_cpu => 80, 

consuraer__group2 => 'my_gro"up2 ' , 

group2_cpu => 20| ; 
END; 
/ 

This statement creates a resource plan called niY_Einiple_planl. To verify the 
resource plan contents, query the view DBA_RSRC_PLANS. An example is the 
following statement: 

SELECT PLAN, STATUS FROM DBA_RSRC_PLAHS ; 

PLAN STATUS 

SYSTEM_PLAN ACTIVE 

IHTERNAL_QUIESCE ACTIVE 

IHTERNAL_PLM ACTIVE 

MY SIMPLE PLMl ACTIVE 



See Also: "Allocating Resources Among jobs ' on page 27-47 for 
further information on resource plans 
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Task 2D: Creating Window Groups 

To create window groups, use the GREATE_WIwr>OW_GROUP and 
ADD_WINDOW_GROUP_MEMBEE procedures. The following statements illustrate an 
example of using these procedures: 

BEGIN 
DBMS_SCHEDDLER.CREATE_WIHI]OW_GR0UP { 

groupjiame => 'my_window_grou.pl', 

coirments => "This is n^ first windovi' group. ' ) ; 

DBMS_SCHEDUI£R.ADD_WIND[M_GROUP_MEMBER ( 
group_naine => 'ii^_window_groupl ' , 

window_list => ' iny_wiiLdowl , iny_window2 ' ] ; 

DBMS_SCHEDULER.ADD_WIND01_GR0UP_MEMBER ( 

group_iiaiiie => 'my_wirLdow_groupl ' , 

yijidow_list => ' my_window3 ' ) ; 

EHD; 
/ 

These statements assume that you have already created mY_wind.ow2 and 

inY_window3. You can do this with the CREATE_WINDOW procedure. 

These statements create a window group called mY_wind.ow_groupl and then add 
inY_windowl, mY_window2, and mY_window3 to it. To verify the window group 
contents, issue the following statements: 

SELECT ' FROM DBA_SCHEDULER_1IND0W_GR0DPS ; 

WI]roOM_GROnP_HAHE EHABLED HUMBER_0F_MrND0W3 COMMENTS 

MY_WINDOW_GROTJP1 TRUE 3 This is my first window group. 

SELECT ' FROM DBA_SCHEDULER_1INGR0UP_HEMBERS; 

WINDOW GROUP NAME WINDOW NAME 



MY_WINDOW_GROUP1 MY_WIIJD0W1 

MY_WINDOW_GROUP1 MY_WIIJD0W2 

MY WINDOW GROUPl MY WIND0M3 



See Also: Oracle Database PL/SQL Packages and Types Reference for 
CREATE_WI]srDOW_GROUP syntax, "Using Window Groups" on 
page 27-30 for further information on window groups, and 
"Example of Creating Window Groups" on page 28-23 for more 
detailed examples of creating window groups 

Task 2E: Setting Scheduler Attributes 

There are several Scheduler attributes that control the behavior of the Scheduler They 

are default_ time zone, log_hi story, niax_ j ob_slave_proces ses, and 
event_expirY_time. The values of these attributes can be set bv using the 
3 ET_3CHEDULER_AT TRIBUTE procedure. Setting these attributes requires the 
MANAGE 3 CHEDULER privilege. Attributes that can be set are: 

■ def ault_timezone 

Repeating jobs and windows that use the calendaring syntax need to know which 
time zone to use for their repeat intervals. They normally retrieve the time zone 
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from start_date, but if no s tart_date is provided (which is not uncommon), 
they retrieve the time zone from the def ault_timezone Scheduler attribute. 

Scheduler derives the value of def ault_timezone from the operating system 
environment. If Scheduler can find no compatible value from the operating 
system, it sets def aul t_ time zone to NULL, 

It is crucial that vou verify that def aul t_ time zone is set properly, and if not, 
that you set it. To verify it, run this query: 

SQL> select dbr[iE_sched.uler .stiine from dual; 

STIME 

14-OCT-04 02.56.03.206273000 PM US/PACIFIC 



To ensure that daylight savings adjustments are followed, it is strongly 
recommended that you set def ault_timezone to a region name instead of an 
absolute time zone offset. For example, if your database resides in Miami, Florida, 
USA, issue the following statement: 

DBMS_SCHEDULER.SET_SCHEDULE3;_ATTRIBUTE{ 'default_timezone' , 'US/Eastern' ) ; 

To see a list of valid region names, run this query: 

SELECT DISTIHCT TZHME FROM VSTIMEZONE_MAMES ; 

If VOU do not properly set def aul t_time zone, the default time zone for 
repeating jobs and windows will be the absolute offset retrieved from 
SYSTIMESTAMP (the time zone of the operating system environment of the 
database), which means that repeating jobs and windows that do not have their 
3tart_date set will not follow daylight savings adjustments. 

log_hi story 

This enables you to control the amount of logging the Scheduler performs. To 
prevent the job log and the window log from growing indiscriminately, the 
Scheduler has an attribute that specifies how much history (in days) to keep. Once 
a day, the Scheduler automatically purges all log entries from both the job log as 
well as the window log that are older than the specified history. The default is 30 
days. 

You can change the default by using the SET_SCHEDULER_ATTRIBUTE 
procedure. For example, to change it to 90 days, issue the following statement: 

DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTEClog_history', ' 90 ' ) ; 

The range of valid values is 1 through 999. 

max_ j ob_slave_pr oces ses 

This enables you to set a maximum number of slave processes for a particular 
system configuration and load. Even though the Scheduler automatically 
determines what the optimum number of slave processes is for a given system 
configuration and load, you still might want to set a fixed limit on the Scheduler If 
this is the case, you can set this attribute. The default value is NULL, and the valid 
range is 1-999. 

Although the number set by max_job_slave_processes is a real maximum, it 
does not mean the Scheduler will start the specified number of slaves. For 
example, even though this attribute is set to 10, the Scheduler might still determine 
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that is should not start more than 3 slave processes. However, if it v^fants to start 
15, but it is set to 10, it will not start more than 10. 

■ even t_expirY_ time 

This enables you to set the time in seconds before an event generated by the 
Scheduler expires (in other words, is automatically purged from the queue). 

See Oracle Database PL/SQL Packages and Types Refercna for detailed information about 
the SET_SCHEDULER_ATTRIBUTE procedure. 

Monitoring and Managing the Scheduler 

The following sections discuss how to monitor and manage the Scheduler: 

■ Viewing the Currently Active Windovi' and Resource Plan 

■ Finding Information AboutCurrentlv Running Jobs 

■ Monitoring and Managing Window and Job Logs 

■ Changing Job Priorities 

■ Monitoring Running Chains 

■ Managing Scheduler Security 

Viewing the Currently Active Window and Resource Plan 

You can view the currently active window and the plan associated with it bv issuing 
the following statement: 

SELECT WIHDOW_HAME, KESOURCEJLAN FROM DBA_SCHEDULER_WINDOWS 
WHERE ACTIVE= ' TRDE ' ; 

WIHDOW_NAME RESOURCEJMH 

MY_WirJD(M10 MY_RESOURCEPLflNl 



If there is no window active, you can view the active resource plan by issuing the 
following statement: 

SELECT ' FROM VSRSRC_PLM; 

Finding Information About Currently Running Jobs 

You can check a job's state by issuing the following statement: 

SELECT JOB_NaME, STATE FROM DBA_SCHEDDLER_J0B3 
WHERE JOB_HAME = ■MY"_EHP_J0B1 ' ; 

JOBJAME STATE 

MY_EMP_J0B1 DISABLED 

In this case, vou could enable the job using the ENABLE procedure. Table 28-1 shows 
the valid values for job state. 

Table 28-1 Job States 

Job State Description 



disabled The job is dis.ibled. 



Administering Oracie Scheduler 28-7 



Moniloring and Managing the Schedjier 



Table 28-1 (Cont.) Job States 



Job State Description 



scheduled The job is scheduled to be executed. 

running The job is currently running. 

completed The job has completed, and is not scheduled to run again. 

stopped The job was scheduled to run once and was stopped while it was 

running. 

broken The job is broken. 

failed The job was scheduled to run once and failed. 

retry scheduled The job has failed at least once and a retry has been scheduled to be 
executed. 

succeeded The job was scheduled to run once and completed successfully 

chain_E tailed The job is of type chain and has no steps running, no steps scheduled 
to run, and no event steps waiting on an event, and the chain 
evaluation_interval is set to HULL, No progress will be made in 
the chain unless there is manual intervention. 



You can check the progress of currently running jobs by issuing the following 
statement: 

SELECT ' FROM ALL_SCHEDULER_RU™iNG_J0B3 ; 

Note that, for the column CPU_USED to show valid data, the initialization parameter 

RESOURCE_LIMIT must be set to true. 

You can find out information about a job that is part of a running chain by issuing the 
following statement: 

SELECT ' FROM ALL_SCHEDULER_RUHHIHG_CHAIHS WHERE JOB_HME= 'MYJOBl ' ; 

You can check whether the job coordinator is running by searching for a process of the 
form c jqNWW. 

See Also: Oracle Database Reference for details regarding the 

■* SCHEDULER RUNNING JOBS and DBA SCHEDULER JOBS 



Monitoring and Managing Window and Job Logs 

Logs have a new entry for each event that occurs so that you can track historical 
information. This is different from a queue, where you only want to track the latest 
status for an item. There are logs for jobs, job runs, and windows. 

Job activity is logged in the *_SCHEDULER_JOB_LOG views. Altering a job is logged 
with an operation of UPDATE. Dropping a job is logged in these views with an 
operation of DROP. 

See Also: Oracle Database Reference for details on the 
*_SCHEDULER_JOB_LOG views and other Scheduler log views. 

Job Logs 

To see the contents of the job log, query the DBA_SCHEDULER_JOB_LOG view. An 
example is the following statement, which shows what happened for past job runs: 
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SELECT JOB_NME, OPERATION, OWNER ET?OM DBA_3CHEDUI£R_J0B_L0G ; 
JOB HME OPERATION OWNER 



MY J0B13 


CREATE 


SYS 


MY_J0B14 


CREATE 


OE 


MY NEW J0B3 


ENABLE 


SYS 


MY_EMP_J0B1 


UPDATE 


SYS 


MY JOBl 


CREATE 


SCOTT 


MY EMP JOBl 


UPDATE 


SYS 


MY_EMP_JOB 


CREATE 


SYS 


MY J0B14 


RUN 


OE 


MY J0B14 


RETRY RUN 


OE 


MY_J0B14 


RETRY_RUN 


OE 


MY J0B14 


RETRY RUM 


OE 


MY J0B14 


RETRY RUM 


OE 


MY_J0B14 


BROKEN 


OE 


MY J0B14 


DROP 


OE 



When logging_level for a job is set to LOGGIWG_FULL, the additional_inf o 
column of the job log contains the before and after values of the modified attribute on 
update operations, and contains the values of all attributes on drop operations. This 
enables you to trace backwards from the current job state to the state of the job on 
previous job runs. 

Job Run Details 

To further analyze each job run — why it failed, what the actual start time was, how 
long the job ran, and so on — query the DBA_SCHEDULER_JOB_RUN_DETAILS view. 
As an example, the following statement illustrates the status formY_jobl4: 

select log_id, job_narne, status, 

to_char(log_date, 'DD-MON-YYYY HH24:MI'} log_date 
from dba_3cheduler_job_ruii_details 
where job_name = 'MY_J0B14'; 

LOG_ID JOB_NAME STATUS LOG_DATE 

69 MY_J0B14 SUCCEEDED 02-JUH-2005 03:14 

124 MY_J0B14 SUCCEEDED 03-JUN-2005 03:15 

133 MY_J0B14 FAILURE 04-JUH-2005 03:00 

145 MY_J0B14 FAILURE 05-JUH-2005 03:01 

For every row in SCHEDULER_JOB_LOG that is of operation RUN, RETRY_RUN, or 
RECOVERY_RUN, there will be a corresponding row in the *_JOB_RUN_DETAILS view 
with the same LOG_ID. LOG_DATE contains the timestamp of the entr}', so sorting by 
LOG_DATE should give you a chronological picture of the life of a job. 

Controlling Job Logging 

You can control the amount of logging that the Scheduler performs on jobs at either a 
class or job level. Normally, you will want to control jobs at a class level as this offers a 
full audit trail. To do this, use the logging_level attribute in the 

CREATE_JOB_CLASS procedure. 

For each new class, the creator of the class must specify what the logging level is for all 
jobs in that class. The three possible options are: 

■ DBMS_ SCHEDULER . LOGGING_OFF 

No logging will be performed for anv jobs in this class. 
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■ DBMS_SCHEDULEE . LOGGIWG_EUNS 

The Scheduler will write detailed information to the job log for all runs of each job 
in this class, 

■ DBMS_SCHEDULEE . LOGGIWG_FULL 

In addition to recording every run of a job, the Scheduler will record all operations 
performed on all jobs in this class. In other words, everv time a job is created, 
enabled, disabled, altered, and so on will be recorded in the log. 

By default, only job runs are recorded. For job classes that have very short and highlv 
frequent jobs, the overhead of recording everv single run might be too much and you 
might choose to turn the logging off. You might, however, prefer to have a complete 
audit trail of everything that happened to the jobs in a specific class, in which case you 
need to turn on full logging for that class. 

The second wav of controlling the logging level is on an individual job basis. You 
should keep in mind, however, that the log in manv cases is used as an audit trail, thus 
if vou want a certain level of logging, the individual job creator must not be able to 
turn logging off. The class- specific level is, therefore, the minimum level at which job 
information will be logged, A job creator can only turn on more logging for an 
individual job, not less. 

This functionalit\' is provided for debugging purposes. For example, if the 

class- specific level is set to record job runs and the job-specific logging is turned off, 

the Scheduler will still log the runs. If, on the other hand, the job creator turns on full 

logging and the class- specific level is set to record runs only, all operations on this 

individual job will be logged. This way, an end user can test his job bv turning on full 

logging. 

To set the logging level of an individual job, vou must use the SET_ATTRIBUTE 
procedure on that job. For example, to turn on full logging for a job called mytes t job, 
issue the following statement: 

DBMS_3CHEDiri£R.SET_ATTRrBUTE [ 

'mytestjob', ' logging_level ' , DBMS_SCHEa)ULES,LDGGIHG_FULL) ; 



See Also: Oracle Database PL/SQL Packages and Types Reference for 
detailed information about the CREATE_JOB_CLASS and 
SET_ATTRIBUTE procedures and "Task2E: Setting Scheduler 
Attributes" on page 28-5 

Window Logs 

A window log has an entry for each time vou do the following: 

Create a window 

Drop a window 

Open a window 

Close a window 

Overlap windows 

Disable a window 

Enable a window 

There are no logging levels for window logging, but every window operation will 
automatically be logged by the Scheduler, 
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To see the contents of the window log, query the DBA_SCHEDULER_WINi:OM_LOG 
view. The following statement shows sample output from this view: 

SELECT LOG_ID, TO_CHAR ( LOG_DATE , 'MM/DD/YYYY' ) , WIHDOW_[JAME, OPERATIOH 
FROM DBA_SCHEDULER_WIHDOW_LOG ; 

LOG_ID TO_CHAR(LO WINDOW_HME OPERATIOH 

1 10/01/2004 Iv-EEKHIGHTJINDOW CREATE 

2 10/01/2004 'riEEKNIGHT_WINDOW UPDATE 

3 10/01/2004 'rfEEKHIGHT_WIHDOW UPDATE 

4 10/01/2004 WEEKEND_WINDOW CREATE 

5 10/01/2004 IvTEKENDJVINDOW UPDATE 

6 10/01/2004 IvTEKENDJV'INDOW UPDATE 
22 10/06/2004 l'JEEKNIGHT_WIHDOW OPEH 

25 10/06/2004 VJEEKNIGHTJINDOW CLOSE 

26 10/06/2004 IvTEKHIGHTJIHDOW OPEU 
29 10/06/2004 'riEEKHIGHT_WINDOW CLOSE 

TheDBA_SCHEDULER_WIHDOWg_DETAILg view provides information about every 
window that was active and is now closed (completed). The following statement 
shows sample output from that view: 

SELECT LOG_ID, WIND01_HAME, ACTUAL_STAET_DATE, ACTUAL_DURATIOH 
FROM DBA_SCHEDULER_WIHDOW_DETAILS ; 

LOG_ID WIMDOW_NAME ACTUAL_STAET_DATE ACTOAL_DURATI 

25 WEEKNIGHTJINDOW 06-OCT-04 03.12.48.832438 PM P3T8PDT +000 01:02:32 
29 WEEKHIGHT_WIHDOW 06-OCT-04 05.19.37.025704 PM P3T8PDT +000 03:02:00 

Notice that log IDs correspond in both of these views, and that in this case the rows in 
the DBA_SCHEDULER_WINDOWS_DETAILS view correspond to the CLOSE operations 

in the DBA_SCHEDULER_WIWDOW_LOG view. 

Purging Logs 

To prevent job and window logs from growing indiscriminately, use the 
SET_SCHEDULER_ATTRIBUTE procedure to specify how much historv" (in days) to 
keep. Once per day, the Scheduler automatically purges all log entries that are older 
than the specified history period from both the job log and the window log. The 
default history period is 30 days. For example, to change the history period to 90 days, 
issue the following statement: 

DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTEClog_history', '90' ) ; 

Some job classes are more important than others. Because of this, vou can override this 
global history setting by using a class- specific setting. For example, suppose that there 
are three job classes (classl, class2, and class 3), and that you want to keep 10 
days of history for the window log, classl, and class 3, but 30 days for class 2, To 
achieve this, issue the following statements: 

DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTEClog_history', ' 10 ' ) ; 
DBMS_SCHEDULER.SET_ATTRIBUTE( 'claEs2 ', ' log_history ' , '30') ; 

You can also set the class- specific history when creating the job class. 

Note that log entries pertaining to steps of a chain run are not purged until the entries 
for the main chain job are purged. 
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Purging Logs Manually 

The PURGE_LOG procedure enables vou to nianiiallv purge logs. As an example, the 
following statement purges all entries from both the job and window logs: 

DBMS_SCHEDt;i^R . PURGE_LOG { ) ; 

Another example is the following, which purges all entries from the jog log that are 
older than three days. The window log is not affected by this statement. 

DBMS_3CHEDUI^R.PURGE_LOG(log_history => i, whichjog => ' JOB_LOG ' ) ; 

The following statement purges all window log entries older than 10 davs and all job 
log entries older than 10 days that relate to jobl and to the jobs in class 2: 

DfflS_SCHEDiri^R.PnRGE_LOG(log_history => 10, job_nams => 'jobl, Eys.class2'); 



Changing Job Priorities 



You can change job priorities by using the SET_ATTEIBUTE procedure. Job priorities 
must be in the range 1-5 with 1 being the highest priority. For example, the following 
statement changes the job priori t\' for mY_ jobl to a setting of 1: 

BEGIH 
DBMS_SCHEDtJI^R.SET_ATTRIBUTE [ 

name => ' irry_emp__j obi ' . 

attribute => ' job_priority ' , 

value => 1} ; 

END; 
/ 

You can verify that the attribute was changed by issuing the following statement: 

SELECT JOB_NME, JOB_PRI0RITY FROM DBA_3CHEDULER_J0BS ; 
JOB_HfiME JOB_PRIORITY 



MY_™P_J0B 3 

MY_EMP_J0B1 1 

MY_NEW_J0B1 3 

MY_NEM_J0B2 3 

MY NEW J0B3 3 



See Also: Oracle Database PL/SQL Packiigcs and Types Reference for 
detailed information about the SET_ATTRIBUTE procedure 



Monitoring Running Chains 



You can check the state of a running chain bv querying the 

■'_SCHEDULER_RUNNING_CHAINS views. The results contain a row describing the 
current state of every step in every running instance of a chain. For example, the 
following statement displays the state of all steps in the running job MY_CHAIN_JOB. 
It also shows the state of all steps of any nested chain jobs that are running or have 
completed. 

SELECT ' FROM tJSER_SCHEDULER_RUM[JING_CHAINS WHERE JOBJAME = 'H¥_CHftIN_JOB ' ; 

See "Using Chains" on page 27^0 for more information regarding chains. 
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Managing Scheduler Security 

YoLL should griint the CREATE JOB system privilege to regular users who need to be 
able to use the Scheduler to schedule and run jobs. You should grant MANAGE 
SCHEDULER to anv database administrator who needs to be able to manage system 
resources. Granting any other Scheduler system privilege or role should not be done 
without great caution. In particular, the CREATE ANY JOB svstem privilege and the 
SCHEDULER_ADMIN role, which includes it, are very powerful because they allow 
execution of code as any user. They should onlv be granted to very powerful roles or 
users. 

A particularly important issue from a securit}' point of view is handling external jobs. 
Only users that need to run jobs outside of the database should be allowed to do so. 
You must grant the CREATE EXTERNAL JOB system privilege to those users. See 
"Creating Remote External Jobs" on page 27-6 for further information. Security for the 
Scheduler has no other special requirements. See Oracle Database Security Guide for 
details regarding securit}'. 

Note: When upgrading from Oracle Database lOg Release 1 to lOg 
Release 2 or later, CREATE EXTERNAL JOB is automatically granted to 
all users and roles that have the CREATE JOB privilege. Oracle 
recommends that you revoke this privilege from users that don't need 
it. 

Enabling and Disabling Remote External Jobs 

Oracle Scheduler (the Scheduler) can schedule and run external jobs on a remote host. 
The remote host does not need an Oracle database installed; however, a Scheduler 
agent must be installed on the remote host so that the scheduling database can start 
remote external jobs on that host and receive job output and error information. The 
agent must register with every database that is to be permitted to start remote external 
jobs on the agent's host computer An initial setup is also required for each database 
that is to run remote external jobs. This setup enables secure communications between 
the database and remote Scheduler agents. 

Enabling remote external jobs involves the following steps: 

1. Setting Up the Database 

2. Installing, Configuring, and Starting the Scheduler Agent 
This section also contains the following topics: 

■ Stopping the Scheduler Agent 

■ Disabling Remote External Jobs 

See Also: "About Remote External Jobs" on page 26-12 



Setting Up tlie Database 



Before a database can execute jobs using a remote Scheduler agent, the agent must be 
registered with the database. To make the registration of remote Scheduler agents 
secure, an agent registration password must be set on the database. You can limit the 
number of Scheduler agents that can register, and you can set the password to expire 
after a specified duration. 

Complete the following steps for each database that is to run remote external jobs. 
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To set up the database to run remote external jobs: 

1. Using SQL 'PI lis, connect to the database as the SYS user. 

See "Connecting to the Database with SQL'Plus" on page 1-7 for instructions, 

2. Enter the following comniand. to verify that the XML DB option is installed: 

SQL> DESC RESOUECE_VIEH 

If XML DB is not installed, this command returns an "object does not exist" error. 



Note: If XML DB is not installed, you must install it before 
continuing. 



3. Enable HTTP connections to the database bv subm.itting the following PL /SQL 
block: 

BEGIH 

DBMS_XDB.SETHTTPPORT(port) ; 
END; 

where port is the TCP port number on which you want the database to listen for 
HTTP connections. 

port must be an integer between 1 and 65536, and for UNIX and Linux must be 
greater than 1023. Choose a port number that is not already in use. 

4. Run the script prvtirsch.plb with following comniand: 

SQL> @?/rdbms/admin/prvtrEch.plb 

5. Set a registration password for the Scheduler agents using the 

SET_AGENT_REGI STRATI ON_PASS procedure. 

The following example sets the agent registration password to mypas sword. 

BEGIH 

DEMS_SCHEDULE3i . SET_AGENT_REGISTRATIOH_PfiSS ( ' mypassword ' ) ; 
END; 



Note: The MANAGE SCHEDULER privilege is required to set an agent 
registration password. See Oracle Database PL/SQL Packages and Types 
Reference for more information on the 

SET_AGENT_REGISTRATION_PASS procedure. 



Installing, Configuring, and Starting the Scheduler Agent 

Before vou can run remote external jobs on a particular remote host, voii must install, 
configure, and start the Scheduler agent on that host. The Scheduler agent is included 
with the installation package for Oracle Database Gateways, which is included in the 
Database Media Pack. It is also available online at: 

http : / /www . oracle . com/ technology/ software/products /database 

The Scheduler agent must be installed in its own Oracle home. 

To install, configure, and start the Scheduler agent on a remote host: 

1. Log in to the remote host. 
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■ For Windows, log in .is an administrator. 

■ For UNIX and Linux, log in as the user under which vou want the Scheduler 
agent to run. This user requires no special privileges. 

2. Run the Oracle Universal Installer (OUI) from the instaUation media for Oracle 
Database Gateway. 

■ For Windows, run setup . exe. 

■ For UNIX and Linux, use the following command: 

I direc torY_pa tii/runlnstaller 

where d±reatory_path is the path to the Oracle Database Gateway installation 
m.edia, 

3. On the OUI Welcome page, chck Next. 

4. On the product selection page, select Oracle Scheduler Agent, and then click 
Next, 

5. On the Specify Home Details page, enter a name and path for a new Oracle home 
for the agent, and then click Next. 

6. On the Oracle Scheduler Agent page, complete these steps: 

a. In the Scheduler Agent Host Name field, enter the host name of the computer 
on which the Scheduler agent is to run, or accept the default host name, 

b. In the Scheduler Agent Port Number field, enter the TCP port number on 
which the Scheduler agent is to listen for connections, and then click Next. 

Choose an integer between 1 and 65535. On UNIX and Linux, the number 
must be greater than 1023. Ensure that the port number is not already in use. 

7. On the Summary page, click Install. 

8. (UNIX and Linux only) When the Oracle Universal Installer prompts you to run 
the script root . sh, enter the following command iis the root user: 

script_pa tii/root . sh 

The script is located in the directon' that vou chose for agent installation. 

9. Exit OUI when installation is complete, 

10. Use a text editor to review the agent configuration parameter file 
schagent . conf , which is located in the Scheduler agent home directory, and 
verify the port number in the PORT= directive. 

You will need this port number when creating remote external jobs. Change any 
other agent configuration parameters as required. 

11. Register the Scheduler agent with a database that is to run remote external jobs on 
the agent's host computer. Use the following command: 

AGENT_HOME/hin/ scYiagent -registerdatabass db_host db_http_j>ort 

where: 

■ db_hos t is the host name or IP address of the host on which the database 
resides, 

■ db_http_port is the port number that the database listens on for HTTP 
connections. You set this parameter previously in "Setting Up the Database" 
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on page 28-13. You can check the port number by submitting the following 
SQL statement to the database: 

SELECT DBMS_XDB.GETHTTPPORT{} FROM DUAL; 

A port number of means that HTTP connections are disabled. 

The agent prompts you to enter the agent registration password that you set in 
"Setting Up the Database" on page 28-13. 

12. Repeat the previous step for each database that is to run remote external jobs on 
the agent's host. 

13. (UNIX and Linux only) Start the Scheduler agent with the following command: 

AGENTJOME/hin/schsigeat -start 



Note: On Windows, a Scheduler agent service is automaticallv 
created and started during installation. The name of the service ends 
with OracleSchedulerExecutionAgent. Do not confuse this 
service with the OracleJobScheduler ser\'ice, which runs on a 
Windows computer on which an Oracle database is installed, and 
manages the running of local external jobs without credentials. 



Stopping the Scheduler Agent 



Stopping the Scheduler agent prevents the host on which it resides from running 
remote external jobs. 

To stop the Scheduler agent: 

■ Do one of the following: 

- On UNIX and Linux, run the following command: 

AGENTJOME/hin/schdigeat -stop 

- On Windows, stop the service whose name ends with 

OracleSchedulerExecutionAgent. 



Disabling Remote External Jobs 



You can disable the capability' of a database to run remote external jobs bv dropping 

the REMOTE_SCHEDULER_AGENT user. 

To disable remote external jobs: 

■ Submit the following SQL statement: 

DROP USER REMOTE_SCHEDULER_AGENT CASCADE; 

Registration of new scheduler agents and execution of remote external jobs is disabled 
until you run prvtrsch. plb again. 



Import/Export and the Scheduler 



You must use the Data Pump utilities (impdp and expdp) to export Scheduler objects. 
You cannot use the earlier import/export utilities (IMP and EXP) with the Scheduler. 
Also, Scheduler objects cannot be exported while the database is in read-onlv mode. 
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An export generates the DDL that was used to create the Scheduler objects. All 
attributes are exported. When an import is done, all the database objects are recreated 
in the new? database. All schedules are stored with their time zones, which are 
maintained in the new database. For example, schedule "Monday at 1 PM PST in a 
database in San Francisco" would be the same if it was exported and imported to a 
database in Germany. 

Although Scheduler credentials are exported, for securit\' reasons, the passwords in 
these credentials are not exported. After vou import Scheduler credentials, vou must 
reset the passwords using the SET_ATTRIBUTE procedure of the DBMS_SCHEDULER 
package. 

See Also: Oiacle Database Utilities for details on Data Pump 

Troubleshooting the Scheduler 

This section contains the following troubleshooting topics: 

■ Understanding Why a Job Fails to Run 

■ Job Recovery After a Failure 

■ Understanding Why a Program Becomes Disabled 

■ Understanding Why a Window Fails to Take Effect 



Understanding Why a Job Fails to Run 



A job mav fail to run for several reasons. Before troubleshooting a job that you suspect 
did not run, check that the job is not running by issuing the following statement: 

SELECT JOB_HAME, STATE FROM DBA_3CHEDDLER_J0B3 ; 

Typical output will resemble the following: 

JOB_HAME STATE 

MY_EMP_JOB DISABLED 

MY_EMP_J0B1 FAILED 

MY_NEW_J0B1 DISABLED 

MY_NEW_J0B2 BROKEH 

M¥"_MM_J0B3 COMPLETED 

There are four types of jobs that are not running: 

■ Failed Jobs 

■ Broken Jobs 

■ Disabled Jobs 

■ Completed Jobs 

See Also: "Job Recovery After a Failure" on page 28-18 

Failed Jobs 

If a job has the status of FAILED in the job table, it was scheduled to run once but the 
execution has faded. If the job was specified as restartable, ail retries have failed. 

If a job fails in the middle of execution, onlv the last transaction of that job is rolled 
back. If your job executes multiple transactions, you need to be careful about setting 
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restartable to TRUE. You can quer}' failed jobs bv querying the 

•_3CHEDULER_J0B_RUN_DETAILS views. 

Broken Jobs 

A broken job is one that has exceeded a certain number of failures. This number is set 
in max_f allures, andean be altered. In the case of a broken job, the entire job is 
broken, and it will not be run until it has been fixed. For debugging and testing, you 
can use the RUN_JOB procedure. 

You can query broken jobs by querying the '"_SCHEDULER_JOBS and 

*_SCHEDULER_JOB_LOG views. 

Disabled Jobs 

A job can become disabled for the following reasons: 

■ Thejob was manually disabled 

■ The job class it belongs to was dropped 

■ The program, chain, or schedule that it points to was dropped 

■ A window or window group is its schedule and the window or window group is 
dropped 

Completed Jobs 

A job will be completed if end_date or niax_runs is reached, (If a job recently 
completed successfully but is scheduled to run again, the job state is SCHEDULED,) 

Job Recovery After a Failure 

The Scheduler attempts to recover jobs that are interrupted when: 

■ The database abnormally shuts down 

■ A job slave process is killed or otherwise fails 

■ For an external job, the external job process that starts the executable or script is 
killed or otherwise fails, (The external job process is ex t job on Unix, On 
Windows, it is the external job service.) 

■ For an external job, the process that runs the end-user executable or script is killed 
or otherwise fails. 

Job recover}' proceeds as follows: 

■ The Scheduler adds an entry to the job log for the instance of the job that was 
running when the failure occurred. In the log entry, the OPERATION is 'RUN', the 

STATUS is 'stopped', and ADDITIOWAL_IWFO contains one of the following: 

- REASON= " Job slave process was terminated" 
REASON= "ORA-01014: ORACLE shutdown in progress" 

■ If res tar table is set to TRUE for thejob, thejob is restarted, 

■ If res tar table is set to FALSE for thejob: 

- If the job is a run-once job and auto_drop is set to TRUE, the job run is done 
and the job is dropped, 

- If thejob is a run-once job and auto_drop is set to FALSE, thejob is disabled 
and the job s tate is set to 'STOPPED', 
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- If the job is a repeating job, tlie Scheduler schedules the next job run and tlie 

job state is set to 'SCHEDULED'. 

When a job is restarted as a result of this recovery process, the new run is entered into 
the job log with the operation 'REC0VERY_RUN'. 

Understanding Why a Program Becomes Disabled 

A program can become disabled if a program argument is dropped or 
nuinber_of_argiiments is changed so that all arguments are no longer defined. 

See 'Using Programs" on page 27-12 for more information regarding programs. 

Understanding Why a Window Fails to Take Effect 

A window can f.iil to take effect for the following reasons: 

■ A window becomes disabled when it is at the end of its schedule 

■ A window that points to a schedule that no longer exists is disabled 

See "Using Windows" on page 27-22 for more information regarding window^s. 

Examples of Using the Scheduler 

This section discusses the following topics: 
Examples of Creating Jobs 
Examples of Creating Job Classes 
Examples of Creating Programs 
Examples of Creating Windows 
Examples of Setting Attributes 
Examples of Creating Chains 

Examples of Creating Jobs and Schedules Based on Events 
Example of Creating a Job In an Oracle Data Guard Environment 

Examples of Creating Jobs 

This section contains several examples of creating jobs. To create a job, you use the 
CREATE_JOB or the CREATE_JOBS procedures. 

Example 28-1 Creating a Single Regular Job 

The following statement creates a single regular job called my_ j obi in the oe schema: 

BEGIH 
DBMS_SCHEDt;LER.CEEATE_JOB ( 

jol)_nanie => ' oe.my_jobl ' , 

JDb_type => 'PLS2L_BL0CK', 

JDb_action => 'BEGIH DBMS_STATS .GATHER_TaBLE_STATS ( ' 'ae' ', 

' 'sales' 'I ; END;', 

start_date => '15-JtJL-03 1 . 00 . 00AM US/Pacific ' , 

repeat_interval => 'FRE2=DAIL¥' , 

end_date => ' 15-SEP-03 1 . 00 . OOM US/Pacific ' , 

enabled => TRHE, 

coirnieiits => 'Gather table statistics'); 
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END; 
/ 

This job gathers table statistics on the sales table. It will run for the first time on July 
15th and then once a day until September 15. To verify that the job was created, issue 
the following statement: 

SELECT JOB_NME FROM DBR_SCHEDULER_JOBS WHERE JOBJME = 'M¥_J0B1'; 

JOBJME 

MY_J0B1 

Example 28-2 Creating a Set of Regular Jobs 

The following example creates a set of regular jobs: 

DECLARE 

new job sys.job; 

newjobarr sys . job_array; 
BEGIN 

-- Create an array of JOB object types 

newj obarr : = sys . j ob_array { ) ; 

-- Allocate sufficient space in the array 
newj obarr . extend ( 5 ) ; 

-- Add definitions for 5 jobs 
FOR i IN 1..5 LOOP 

— Create a JOB object type 

newjob := sys . j ob ( j ob_name => 'TE3TJ0B' || to_char{i), 

job_Etyle => 'REGULAR', 

j ob_template => ' PROGl ' , 

repeat_interval => 'FREQ=MI[roTELY; INTERVAL_15 ' , 

Etart_date => sys times tang) + interval '600' second, 

raax_runs => 2, 

auto_drop => FALSE, 

enabled > TRUE 



-- Add it to the array 
newj obarr { i ) : = newj ob ; 
END LOOP; 

-- Call CREATE_JOBS to create jobs in one transaction 
DBMS_SCHEDULER . CREATE. JOBS { newj obarr , ' TRANSACTIONAL ' } 

END; 

/ 



Example 28-3 Creating a Set of Lightweight Jolts 

The following example creates a set of lightweight jobs in one transaction: 

DECLARE 

newj ob sys . j ob ; 

newjobarr sys . job_array; 
BEGIN 

newjobarr := sys . job_array { } ; 

new j obarr . extend ( 5 ) ; 

FOR i IN 1. .5 LOOP 

newjob := sys . j ob ( j ob_name => 'lwjob_' || to_char[i}. 
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job_Etyle => 'LIGHTWEIGHT', 

j ob_teir[plate => ' PROGl ' , 

repeat_interv-al => 'FEEQ=MINUTELY; INTERVM,=15 ' , 

start_date => sys times tamp + interval '10' second, 

enabled => TRDE 



new] obarr { i ) : = new j 6b ; 
end loop; 

DBHS_SCHEDDLER. CEEATEJOBS {newj obarr , ' TRMSACTIOHAL ' 
END; 
/ 



See Also: Oracle Database PL/SQL Packages and Types Reference for 
detailed iniormation about the CREATE_JOB procedure and 
"Creating jobs" on page 27-2 for further information 



Examples of Creating Job Classes 



This section contains several examples of creating job classes. To create a job class, you 
use the CREATE_JOB_CLASS procedure. 

Example 28-4 Creating a Jtd> Class 

The following statement creates a job class: 

BEGIN 

DBMS_SCHEDDLER.CREATE_JOB_CLASS [ 

j ob_claEE_naine => 'my_classl', 

service => 'my_3ervicel ' , 

comments => 'This is my first job class'); 

EKD; 

/ 

This creates my_clas si in SYS. It uses a service called mY_servicel, To verify that 
the job class was created, issue the following statement: 

SELECT JOB_CLASS_MME FROM DBA_SCHEDULER_J0B_CLASSE3 
WHERE JOB_CLASS_HAME = 'MY_CLASS1'; 

JOB_CLASS_KfiME 

MY_CLaSSl 

Example 28-5 Creating a Jsd) Class 

The following statement creates a job class: 

BEGIH 
EBMS_SCHEDULER.CEEATE_JOB_CLASS ( 

j Db_class_naine => ' f inancej oba ' , 

resource_cons"umer_grciup => ' f inance_group ' , 

service => 'accounting', 

comments => 'All finance jobs'); 
EHD; 
/ 

This creates f inance_jobs in SYS. It assigns a resource consumer group called 
f inance_group, and designates service affinit\' for the accounting service. Note 
that if the accounting service is mapped to a resource consumer group other than 
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f inance_group, jobs in this class run under the f inance_group consumer group, 
because tlie resource_consunier_group attribute takes precedence. 

See Also: Oracle Database PL/SQL Packages and Types Reference for 
detailed information about the CREATE_JOB_CLASS procedure 
and "Creating Job Classes" on page 27-22 for further information 



Examples of Creating Programs 



This section contains several examples of creating programs. To create a program, you 
use the CEEATE_PEOGRAM procedure. 

Example 28-6 Creating a Program 

The following statement creates a program in the oe schema: 

BEGIH 
DBMS_SCHEDiri£R.CEEATE_PROGRAM ( 

progranLnaine => 'oe.my_prograiiil ' , 

prograin_type => 'PLSQLJLOCK' , 

program_action => 'BEGIN DBMS_STATS . GATHER_TaBLE_STATS ( ' 'oe' ', 

' 'sales' ' ) ; END; ' , 

ri"uiiiber_of_argumentE => 0, 

enabled => TRDE, 

comments => 'My ctxnments here ' ] ; 

END; 
/ 

This creates my _progr ami, which uses PL /SQL to gather table statistics on the sales 
table. To verify that the program was created, issue the following statement: 

SELECT PROGRAM_NAME FROM DBA_3CHEDDLER_PR0GRAMS 
WHERE PROGRAM_HAME = 'MY_PR0GRAM1 ' ; 

PROGRAMJAME 

MY_PR0GRAM1 

Example 28-7 Creating a Program 

The following statement creates a program in the oe schema: 



BEGIH 

DBMS SCHEDUI£R. CREATE PROGRAM 





program_ 


_naine 


=> 


' oe. 


. my_s a ved_j>r o gr ami 




program_ 


.action 


=> 


' /usr/local/bin/date ' 




prograiTL 


-type 


=> 


' EXECUTABLE ' , 




comments 


=> 


'Hy 


comments here' } ; 


END; 
/ 











This creates my_saved_programl, which uses an executable. 

See Also: Oracle Database PL/SQL Packages and Types Refcretice for 
detailed information about the CREATE_PROGRAM procedure and 
"Creating Programs" on page 27-12 for further information 



Examples of Creating Windows 



This section contains several examples of creating windows. To create a window, vou 
use the CREATE_WINDOW procedure. 
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Example 28-8 Creating a Window 

The folJowing statement creates a window called mY_windowl in SYS: 

BEGIH 

DBMS SCHEDULER. CREA'FE WIHDOW ( 



window_riaine 


=> 


' ray_windawl ' , 


r es our c e_plan 


=> 


'my_res_plaiil ' , 


start_date 


=> 


'15-JUL-03 l.OO.OOM DS/Pacific', 


repeat_interval 


=> 


■FREQ=DAILY', 


end._da te 


=> 


■15-SEP-03 l.OO.OOM US/Pacific ' , 


duration 


=> 


interval '80' MIHUIE, 


comments 


=> 


'This is my first window' ) ; 


EHD; 
/ 







This window will open once a dav at 1AM for 80 minutes ever}' dav from Mav 15th to 
October lEith, To verify that the window was created, issue the following statement: 

SELECT WIHDOWJfflE EROM DBA_SCHEDULER_WINDOMS WHERE WINDOW_MME = 'H¥"_WIND0W1 ' ; 

wnmoiis_SME 
MY_wiiraowi 

Example 28-9 Creating a Window 

The following statement creates a window called mY_window2 in SYS: 

BEGIH 
DBMS.SCHEDtlLER.CHEAIE.HrffiDOM ( 

wiiidow_name => ' iiY_window2 ' , 

schedule_name => 'my_stats_schedule' , 

resource_plan => 'my_reEourceplanl ' , 

duration => interval '60' minute, 

coirments => 'My window' ) ; 
EKP; 
/ 

See Also: Oracle Database PL/SQL Packages and Types Reference for 
detailed information about the CREATE_WINDOW procedure and 
"Creating Windows" on page 7.7-Th for further iniormation 



Example of Creating Window Groups 



This section contains an example of creating a window group. To create a window 
group, you use the CREATE_WINDOW_GROUP procedure, 

Example28-10 Crealinga Window Group 

The following statement creates a window group called mY_window_groupl: 

BEGIH 

EBMS_SCHEDOLER.CHEATE_WINDOW_GR0tJP { 'iny_windowgroupl ' ) ; 

EHD; 

/ 

Then, you could add three windows (mY_windowl, mY_window2, and mY_window3) 
to mY_window_groupl bv issuing the following statements: 

BEGIH 

DBMS SCHEDULER. ADD WINDOM GROUP MEMBER ( 
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groupjiame => 'my_window_groupl ' , 
window_list => 'ray_windowl, iny_wiTidow2 ' ) ; 

DBMS_SCHEDiri£R.ADD_WINDOM_GROUP_MEMBER ( 

group_naine => 'ray_window_groupl ' , 

window_list => ' ray_window3 ' ) ; 
END; 
/ 

To verify that the window group was created and the windows added to it, issue the 
following statement: 

SELECT ' FROM DBa_SCHEDULER_MIND0W_GROUP3 ; 

WIHD[M_GRODP_HflHE ENABLED HDHBER_0F_WINDOWS COMMENTS 

MY_WIHDOW_GROUP1 TRUE 3 This is my first window group 

See Also: Oracle Database PL/SQL Packages and Types Reference for 
detailed information about the CREATE_WINDOW_GROUP and 
ADD_WI]srDOW_GROUP_MEMBER procedures and "Creating Window 
Groups" on page 27-30 for further information 



Examples of Setting Attributes 



This section contains several examples of setting attributes. To set attributes, you use 

SET_ATTRIBUTE and SET_SCHEDULER_ATTRIBUTE procedures. 

Example 28-1 1 Setting the Repeat Interval A ttribute 

The following example resets the frequency my_emp_ j obi will run to daily: 

BEGIH 
DfflS_SCHEDULER.SET_ATTRIBnTE [ 

name => ' my_emp__j abl ' , 

attribute => ' repeat_interval ' , 

value => 'FREQ=DAILY' ) ; 
END; 
/ 

To verify the change, issue the following statement: 

SELECT JOB_NAME, REPEAT_INTERVAL FROM DBA_SCHEDULER_JOBS 
WHERE JOB_NAME = 'MY"_EMP_J0B1 ' ; 

JOB_KaME REPEAT_INTERVAL 

MY_FMP_J0B1 FREQ=DAILY 

Example 28-12 Setting the Comments Attribute 

The following example resets the comments for mY_saved_prograinl: 

BEGIH 
DBMS_SCHEDirLER.SET_ATTRIBnTE [ 

name => 'my_saved_programl ' , 

attribute => 'comments', 

value => 'For nightly table stats'); 

END; 
/ 
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To verify the change, issue the following statement: 

SELECT PROGRAM.NME, COMMENTS FROM DBA_SCHEDUI£R_PEOGRMS ; 
PROGRM HftME COMMENTS 



MY_PE0GRM1 My comments here 

MY_SAVED_PR0GRM1 For nightly table stats 

Example 28-13 Setting the Duration Attribute 

The following example resets the duration of m.Y_wind.ow3 to 90 minutes: 

BEGIN 

DBMS_SCHEDUI£R.SET_ATTRIBUTE ( 

name => 'my_window3 ' , 

attribute => 'duration', 

value => interval '90' minute); 

END; 
/ 

To verify the change, issue the following statement: 

SELECT WIMDOW_HAME, DUEATIOH FROM DBA_SCHEDULER_WIHDOWS 
WHERE WINDOWJfiME = 'MYJINDOWS ' ; 

WIMDOM_NME DURATION 

MY_WIND0W3 +000 00:90:00 

Example 28-14 Setting the Database Role Attribute 

The following example sets the database role of the job mY_ j ob to LOGICAL STANDBY. 

BEGIN 
DBMS_SCHEDUI£R.SET_ATTRIBUTE ( 

name => 'my_job', 

attribute => ' databaEe_role ' , 

value => • LOGICAL STANDBY ' ) ; 
END; 
/ 

To verify the change in database role, issue the following command: 

SELECT JOB_NAME, DATABASE_ROLE FROM DBA_SCHEDULER_JOB_ROI£S 
WHERE JOB_NAME = 'MY_JOB'; 

JOB_HAME DATABASE_ROLE 

MY_JOB LOGICAL STANDBY 

Example 28-15 Setting the Event Expiration Attribute 

The following example sets the time in seconds to 3600 when an event expires: 

BEGIN 

DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE ( 

attribute => event_expiry_time. 

value => 3600); 
END; 
/ 
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Example 28-16 Setting Multiple Job Attributes for a Set of Regular Jobs 

The folJowing example sets four different attributes for eacli of tlie five regular jobs 
created in Example 28-2, "Creating a Set of Regular Jobs" on page 28-20: 

DECLME 

newattr sys.jobattr; 

newattrarr sys . jobattr_arraY; 

] number; 
BEGIN 

— Create new JOEATTR array 

newattrarr := sys . ]obattr_array [ ] ; 

-- Allocate enough space in the array 

newattrarr . extend (20); 

j := 1; 

FOR i IH 1..5 LOOP 

— Create and initialize a JOBATTR object type 

newattr := sys . jobattr ( job_naiiie => 'TESTJOB' || to_cliar(i), 
attr_name => '^ffiX_FAILDRE3 ' , 
attr_value => 5); 

-- Add it to the array. 

newatt:rarr ( j ) := newattr; 

: := ] + 1; 

newattr := sys . jobattr ( job_name => 'TESTJOB' || to_char(i], 

attr_naine => 'COMMENTS', 

attr_value => 'Bogus comment'); 
newattrarrf j ) := newattr; 
j :=]+!; 
newattr := sys . jobattr [job_naine => 'TESTJOB' || to_char(i], 

attr_naine => 'END_DATE', 

attr_value => sys times tamp + interval '24' hour); 
newattrarr (j ) := newattr; 
j := j + 1; 
newattr := sys . jobattr (job_name => 'TESTJOB' || to_char(i], 

attr_name => '3CHEDULE_LIMIT' , 

attr_value => interval '1' hour); 
newatt:rarr ( j ) := newattr; 
j := j + 1; 
END LOOP; 

-- Call SET_JOB_ATTRIBIJTES to set all 20 set attributes in one transaction 
DBMS_SCHEDULER.SET_JOB_ATTRIBUTES (newattrarr, 'TRANSACTIONAL' }; 

END; 

/ 



Example 28-17 Setting Attributes for a Set of Lightweight Jobs 

The following example sets multiple attributes for a set of lightweight jobs. Note that 
not all regular job attributes are supported for lightweight jobs; 

DECLARE 

newattr sys. jobattr; 

newattrarr sys. jobattr_array; 

j number ; 
BEGIN 

— Create new JOBATTR array 
newattrarr := sys . jobattr_array ( ) ; 

— Allocate enough space in the array 
newattrarr .extend[10) ; 
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j := 1; 

FOR i IH 1. .5 LOOP 

-- Create and initialize JOBATTR object type 

newattr := sys . jobattr [ job_naTne => 'lwjob_' || tci_char{i), 
attr_naine => 'END_DATE', 
attr_value => sys times tamp + interval 

— Add. it to array. 

newattrarrf j ) := newattr; 

j :=]+!; 



24 ' hour) 



newattr := sys . jobattr [job_naiiie => 'lwJDb_' || to_char{i), 

attr_Daine => 'RESTARTABI£ ' , 

attr_value => TRUE) ; 
newattrarr ( j ) := newattr; 
j := j + 1; 
END LOOP; 

-- Call SET_JOB_ATTHIBDTES to set all 20 set attributes in one transaction 
DBHS_SCHEDDLER.SET_JOB_ATTRIBDTES (newattrarr, ' TRANSACT I OHAL ' }; 

EHD; 

/ 



See Also: Oracle Dninbase PL/SQL Packages and Types Reference for 
detailed information about tfie SET_SCHEDULER_ATTRIBUTE 
procedure and "Task2E: Setting Scheduler Attributes" on page 28-5 



Examples of Creating Chains 



This section contains examples of creating chains. To create chains, vou use the 
CREATE_CHAIW procedure. After creating a chain, vou add steps to the chain with the 
DEFIWE_CHAIW_STEP procedure and define the rules with the DEFINE_CHAIN_RULE 
procedure. 

Example 28-18 Creating a Chain 

The following example creates a chain where inY_prograinl runs before 
inY_prograi[i2 and my_program3, my_program2 and r[iY_program.3 run in parallel 
after mY_progr ami has completed. 



BEGIN 




DBMS_SCHEDULER . CREATE_CHAIN 


( 


chain_name => 


' my_cha inl ' , 


rule_set_nanie => 


NOLL, 


evaluation_interval => 


NULL, 


comments => 


NULL] ; 


END; 





/ 



define three steps for this chain. 

BEGIN 

DfflS_SCHEDirLER.DEFINE_CHAIN_STEP [ 'iny_chainl ' , ' stepl ' 

DBMS_SCHEDULER.DEFINE_CHAIN_3TEP [ 'iny_chainl ' , ' step2 ' 

DBMS_SCHEDULER.DEFINE_CHAIN_STEP ( 'iny_chainl ' , ' step3 ' 

EHD; 

/ 



'iny_programl ' 
'iny_program2 ' 
'iny_prcigram3 ' 



define corresponding rules for the chain. 

BEGIN 

DBMS_SCHEDDLER.DEFIHE_CHAIN_Rtri£ ( 'iny_chainl ' , ' TRUE ' , 'START stepl ' 
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'Start step2, step3 ' J 



DBMS_SCHEDUI£R . DEFIHE_CHAIN_Rtri£ 

'iny_chainl', 'stepl COMPLETED' 
DBMS.SCHEDULER.DEFIHE.CHAIN.RULE ( 

'my_chainl', 'step2 COHPtETED SKD step3 COMPLETED' 
END; 
/ 



'END' 



Example 28-19 Creating a Chain 

The folJowing example creates a chain where first mY_progr ami runs. If it succeeds, 
my_program2 runs; otherwise, mY_progjrain3 tuns. 



BEGIH 

DBMS SCHEDULER. CREATE CHAIN 



chain_naiiie 

r ule_s e t_nanie 

eva lua t i oiL_interva 1 

comments 
END; 
/ 



=> 'ray_cfsain2 ' 
=> HULL, 
=> HULL, 
=> HULL) ; 



define three steps for this chain. 

BEGIH 

DBMS_SCHEDULER.DEFIHE_CHAIN_STEP[ 'my_chain3', 

DBMS_SCHEDULER.DEFIHE_CHAIH_STEP [ 'iny_chain2 ' , 

DBMS_SCHEDULER.DEFIHE_CHAIH_STEP [ 'iny_chain2 ' , 

END; 

/ 



' stepl ' 
'step2' 
' step3 ' 



'my_programl ' 
'iny_program2 ' 
'iny_program3 ' 



define corresponding rules far the chain. 

BEGIH 

DBMS_SCHEDULER.DEFIHE_CHAIN_RULE ( 'iiiy_chain2 ' , 'TRUE', 'START stepl'); 

DBMS_SCHEDULER.DEFIHE_CHAIN_RULE ( 

'my_chain2', 'stepl SUCCEEDED', 'Start step2 ' ) ; 
DBMS_SCHEDULER.DEFIHE_CHAIN_RULE ( 

'i[5'_chain2', 'stepl COMPLETED AND stepl HOT SUCCEEDED', 'Start step3 ' ) ; 
DBMS_SCHEDULER.DEFIHE_CHAIN_RULE ( 

'my_chain2', ' step2 COMPLETED OR step3 COMPLETED', 'END'); 
END; 
/ 

See Also: Oracle Database PL/SQL Packages and Types Reference for 
detailed information about the CREATE_CHAIN, 

DEFINE_CHAIN_STEP, and DEFINE_CHAIN_RULE procedures and 
"Task 2E: Setting Scheduler Attributes" on page 28-5 

Examples of Creating Jobs and Schedules Based on Events 

This section contains examples of creating event-based jobs and event schedules. To 
create event-based jobs, you use the CREATE_JOB procedure. To create event-based 
schedules, you use the CREATE_EVENT_SCHEDULE procedure. 

These examples assume the existence of an application that, when it detects the arrival 
of a file on a svstem, enqueues an event onto the queue mY_events_q. 

Example 28-20 Creating an Event-Based Schedule 

The following example illustrates creating a schedule that can be used to start a job 
whenever the Scheduler receives an event indicating that a file arrived on the system 
before 9 AM: 
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BEGIN 
DBMS_SCHEDULER.CEEATE_EVENT_SCHEDULE | 

sched"ule_naiiie => 'scott . f ile_arrival ' , 

start_date => sys times tamp, 

event_condition => ' tal).user_data.obje<:t_owner = ''SCOTT'' 
and tab.user_data.eveiit_naiiie = ' 'FIIjE_AREIVAL ' ' 
and extract hour from tab.uEer_data.event_timestarnp ■: 9', 
queue_spec => ' n^_everits_q ' ) ; 

END; 
/ 

Example 28-21 Creating an Event-Based Job 

The following example creates a job that starts when the Scheduler receives an event 
indicating that a file arrived on the system: 

EEGIH 

DBMS 3CHEDUI£R. CREATE JOB ( 



j ob_name 


=> 


iny_ j oh , 


pr ogr anLname 


=> 


my_program. 


start_date 


=> 


'15-JUL-04 1.00.00AM US/Pacific', 


everit_condition 


=> 


' tab.user_data.event_name = ' 'FILE_AHRIVAL' 


queue_spec 


=> 


' iiiy_eventE_q ' 


enabled 


=> 


TRUE, 


conments 


=> 


'niy event-based job'}; 


EHD; 
/ 







See Also: Oracle Database PL/SQL Packages and Types Reference for 
detailed information about the CREATE_JOB and 

CREATE_EVENT_SCHEDULE procedures 

Example of Creating a Job In an Oracle Data Guard Environment 

In an Oracle Data Guard environment, the Scheduler includes additional support for 
two database roles: primarv and logical standby. You can configure a job to run only 
when the database is in the primary role or only when the database is in the logical 
standby role. To do so, you set the database_role attribute. This example explains 
how to enable a job to run in both database roles. The method used is to create tv^fo 
copies of the job and assign a different database_role attribute to each. 

By default, a job runs when the database is in the role that it was in when the job was 
created. You can run the same job in both roles using the following steps: 

1. Copy the job 

2. Enable the new job 

3. Change the database_role attribute of the new job to the required role 

The example starts bv creating a job called priniarY_job on the primary database. It 
then makes a copy of this job and sets its database_role attribute to 'LOGICAL 
standby'. If the primar}' database then becomes a logical standbv, the job continues to 
run according to its schedule. 

When you copy a job, the new job is disabled, so you must enable the new job. 

BEGIN 

DBMS_SCHEDULER.CREATE_JOB ( 

job_name => 'primary_job' , 

program_name => 'iiiy_prog' , 
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schedule_name => 'ir[y_sched ' ] ; 

DBMS_3CHEDULER.C0P¥_J0BCprimary_job', ' standby_job' ) ; 

DBMS_SCHEDiri£R.ENABLE[name=>'Etandby_job', commit_seiiiantics=> ' ABSORB_ERROHS ' ) ; 
DBMS_3CHEDULER.SET_ATTRIBDTE( ' standby _j ob ' , 'databass.role' , 'LOGICAL STANDBY' ) ; 
END; 
/ 

After you execute this example, the data in the DBA_SCHEDULER_JOB_ROLES view is 
as follows: 

SELECT JOB_NAME, DATABASE_ROLE FRCM DBA_3CHEDULER_J0B_R0LES 
WHERE JOBJAHE IH ( ' PRIMARY_JOB ' , ' STANDBY_JOB ' ) ; 

JOB_HAME DATSBASEJHOLE 



PRIMARY_JOB PRIMARY 

STABDBY JOB LOGICAL STANDBY 



Note: For a physical standby database, any changes made to 
Scheduler objects or any database changes made bv Scheduler jobs on 
the primar;' database are applied to the physical standby like anv 
other database changes. 

Scheduler Reference 

This section contains reference iniormation for Oracle Scheduler It contains the 
following topics: 

■ Scheduler Privileges 

■ Scheduler Data Dictionary Views 

Scheduler Privileges 

Table 28-2 lists the various Scheduler privileges. 

Table 28-2 Scheduler Privileges 
PrivilegeName OperationsAuthorized 

System Privileges; 

CREATE JOB Tliis privilege enables you to create jobs, chains, schedules, programs, and 

credentials in your own schema. You will alwaysbe able to alter and drop jobs, 
schedules and programs in your own schema, even it you do not have the CREATE 
JOB privilege. In this case, the job must have been created in your schema by 

another user with the CREATE AMY JOB privilege. 

CREATE AMY JOB This privilege enables you to create, alter, and drop jobs, chains, schedules, 

programs, and regular credentials in any schema except SYS, This privilege is very 
powerful and should be used with care because it allows the grantee to execute 
code as any other user 

CREATE EXTERMAL JOB This privilege is required to create jobs that run outside of the database. Owners of 
jobs of type 'EXECUTABLE' or jobs that point to programs of type 'EXECUTABLE' 
require this privilege. To run a job of type 'EXECUTABLE', you must have this 
privilege and the CREATE JOB privilege. Tliis privilege is also required to retrieve 
files from a remote host and to save files to one or more remote hosts. 

EXECUTE ANY PROGRAM This privilege enables your jobs to use programs or chains from any schema. 

EXECUTE ANY CtjASS This privilege enables your jobs to run under any job class. 
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Table 28-2 (Cont.) Scheduler Privileges 



Privilege Name 



Operations Authorized 



MANAGE SCHEDULER 

Object Privileges: 

EXECUTE 

ALTER 



ALL 



This is the most important privilege for administering the Scheduler, It enables 
you to create, alter, and drop job classes, windows, and window groups It also 
enables you to set and retrieve Scheduler attributes, purge Scheduler logs, drop 
public credentials, set the agent password tor a database. 



This privilege can only be granted for programs, chains, and job classes. It enables 
you to create a job that runs with the program, chain, or job class. It also enables 
you to view object attributes. 

This privilege enables you to alter or drop the object it is granted on. Altering 
includes such operations as enabling, disabling, defining or dropping program 
arguments, setting or resetting job argument values and running a job. For 
programs, jobs, and chains, this privilege enables you to view object attributes. 
This privilege can only be granted on jobs, chains, programs and schedules. For 
other types of Scheduler objects, you can grant the MAMAGE SCHEDULER system 
privilege. This privilege can be granted for: 

jobs [DEOP_J0B, RUH_JOB, ALTEE_RUMHIHG_CHAIH, 
SET_J0B_ARGUMEHT_VALUE,RESET_JOB_ARGUMENT_VALUE, 
SET_JOB_AHYDATA_VALUE) and (STOP_JOB without the force option) 

chains (DEOP_CHAIH, ALTER_CHAIM, DEFIHE_CHAIN_RULE, 

DEFIHE_CHAIN_STEP, DEFINE_CHAIN_EVEfiT_STEP, HROP_CHAIH_RULE, and 
DROP_CHAIW_STEP) 

programs (DROP_PROGRAM, DEFIHE_PROGRAM_ARGUMEHT, 

DEFIHE_AHYI>ATA_ARGUMEHT, DEFIHE_HETADATA_ARGUMEHT, 
DROP_PR0GRAH_ARGUMEHT, SET_ATTRIBUTE_NULL) 

schedules (DROP_SCHEDULE) 

This privilege authorizes operations allowed by all other object privileges possible 
for a given object. It can be granted on jobs, programs, chains, schedules and job 
classes. 



The SCHBDULER_ADMIN role is created with all of the system privileges shown in 
Table 28-2 (with the ADMIN option). The SCHEDULER_ADMIN role is granted to DBA 
(with the ADMIN option). 

The following object privileges are granted to PUBLIC: SELECT ALL_SCHEDULER_* 

views, SELECT USER_SCHEDULER_' views, SELECT 

SYS. SCHEDULER S_JOBSUFFIX_S (for generating a job name), and EXECUTE 

SYS. DEFAULT JOB CLASS, 



Scheduler Data Dictionary Views 



You can check Scheduler information by using many views. An example is the 
following, which shows information for completed instances of niY_jobl: 

SELECT JOB_HME, STATUS, EERORtt 

FROM DBA SCHEDULER JOB RUH DETAILS WHERE JOB NAME = 'MY JOBl ' ; 



JOB HAME 



MY JOBl 



STATUS 



FAILURE 



ERHORl 



2 0000 



Table 28-3 contains views associated with the Scheduler The 

■*_3CHEDULER_SCHEDULES, *_SCHEDULER_PROGRAMS, 
■*_SCHEDULER_RUNNING_JOBS, *_SCHEDULER_JOB_LOG, 



SCHEDULER JOBS, 
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*_SCHEDULER_JOB_RUN_DETAILS views are particularly useful for managing jobs. 
See Oracle Database Reference for details regarding Scheduler views. 

Note: In the following table, the asterisk at the beginning of a view 
name can be replaced with DBA, ALL, or USER. 



Table 28-3 Scheduler Views 



View 



Description 



_3CHEDULER_SCHEa)ULES 

_3CHEDULER_PR0GRMS 

_3CHEDULER_PR0GRftH_ARGS 

.SCHEDULER. JOBS 

_3CHEDULER_RUNHIMG_CHftINS 

_3CHEDULER_CHAIH_STEPS 

_3CHEDDLER_CHAIH3 

_3CHED0LER_CHAIH_RULES 

_3CHEDDLER_GL0BAL_ATTRIBUTE 

_3CHEDDLER_J0B_ARGS 
_3CHEDULER_J0B_CLAS3ES 
_3CHEDDLER_WIND01S 
_3CHEDDLER_J0B_RUH_DETAILS 

_3CHEDULER_WIND0M_GR0UP3 
_3CHEDULER_WIHGR0UP_MEMBER3 

_3CHEDULER_RUNHING_J0BS 

_3CHEDULER_J0B_L0G 
_3CHEDULER_WIND01_L0G 
_3CHEDULER_WIND01_DETAILS 
_3CHEDULER_CREDENTIALS 
SCHEDULER JOB ROLES 



These views show iiU schedules. 

These views show all programs. 

These views show all arguments defined for all 
programs as well as the default values if they exist 

These views show all jobs, enabled as well as disabled. 

These views show all chains that are running. 

These views show all steps for all chains. 

These views show all chains. 

These views show all rules tor all chains. 

These views show the current values of Scheduler 
attributes. 

These views show all set argument values for all jobs. 

These views show all job classes. 

These views show all windows. 

These views show all completed (failed or successful) job 
runs. 

These views show all window groups. 

These views show the members of all window groups, 
one row for each group member 

These views show state information on all jobs that are 
currently being run. 

These views show all state changes made to jobs. 

These views show all state changes made to windows. 

These views show all completed window runs. 

These views show all credentials. 

These views show all jobs by Oracle Data Guard 
database role. 
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Part VII discusses the management of a distributed database environment. It contains 
the following sections: 



Chapter 29, 
Chapter 30, 
Chapter 31, 
Chapter 32, 



Distributed Database Concepts" 

Managing a Distributed Database" 

Developing Applications for a Distributed Database System" 

Distributed Transactions Concepts" 



Chapter 33, 'Managing Distributed Transactions" 
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In this chapter: 

Distributed Database Architecture 

Database Links 

Distributed Database Administration 

Transaction Processing in a Distributed System 

Distributed Database Apphcation Development 

Character Set Support for Distributed Environments 



Distributed Database Architecture 

A distributed database system allows applications to access data from local and 
remote dat.ibases. In a homogenous distributed database system, each database is an 
Oracle Database. In a heterogeneous distributed database system, at least one of the 
databases is not an Oracle Database. Distributed databases use a client/server 
architecture to process information requests. 

This section contains the following topics: 

■ Homogenous Distributed Database Svstems 

■ Heterogeneous Distributed Database Systems 

■ Client/Server Database Architecture 

Homogenous Distributed Database Systems 

A homogenous distributed database system is a network of two or more Oracle 
Databases that reside on one or more machines. Figure 29-1 illustrates a distributed 
svstem that connects ttu'ee databases: hq, mf g, and sales. An application can 
simultaneously access or modify the data in several databases in a single distributed 
environment. For example, a single query from a Manufacturing client on local 
database mfg can retrieve joined data from the products table on the local database 
and the dept table on the remote hq database. 

For a client application, the location and platform of the databases are transparent. 
You can also create synonyms for remote objects in the distributed system so that 
users can access them with the same svntax as local objects. For example, if vou are 
connected to database mfg but want to access data on database hq, creating a 
synonym on mfg for the remote dept table enables you to issue this querv: 

SELECT ' FROM dept; 
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In this wav, a distributed system gives the appearance of native data access. Users on 
mf g do not liave to know that the data they access resides on remote databases. 



Figure 29-1 Homogeneous Distributed Database 



lUlanufacturing 



Headquarters 




a J d 



An Oracle Database distributed database system can incorporate Oracle Databases of 
different versions. All supported releases of Oracle Database can participate in a 
distributed database svstem. Nevertheless, the applications that work with the 
distributed database must understand the functionalitv that is available at each node 
in the svstem. A distributed database application cannot expect an Oracle? database to 
understand the SQL extensions that are onlv available with Oracle Database. 

Distributed Databases Versus Distributed Processing 

The terms distributed database and distributed processing are closely related, yet 
have distinct meanings. There definitions are as follows: 

■ Distributed database 

A set of databases in a distributed system that can appear to applications as a 
single data source. 

■ Distributed processing 

The operations that occurs when an application distributes its tasks among 
different computers in a network. For example, a database application tvpically 
distributes front-end presentation tasks to client computers and allows a back-end 
database server to manage shared access to a database. Consequentiv, a 
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distributed database application processing svsteni is more commonly referred to 
as a client /server database application system. 

Distributed database systems employ a distributed processing architecture. For 
example, an Oracle Database server acts as a client when it requests data that another 
Oracle Database server manages. 

Distributed Databases Versus Replicated Databases 

The terms distributed database system and database replication are related, vet 
distinct. In a pure (that is, not replicated) distributed database, the system manages a 
single copy of all data and supporting database objects, Typicallv, distributed database 
applications use distributed transactions to access both local and remote data and 
modify the global database in real-time. 



Note: This book discusses only pure distributed databases. 

The term replication refers to the operation of copying and maintaining database 
objects in multiple databases belonging to a distributed system. While replication 
relies on distributed database technology, database replication offers applications 
benefits that are not possible within a pure distributed database environment. 

Most commonly, replication is used to improve local database performance and 
protect the availability of applications because alternate data access options exist For 
example, an application may normallv access a local database rather than a remote 
server to minimize network traffic and achieve maximum performance. Furthermore, 
the application can continue to function if the local server experiences a failure, but 
other servers with replicated data remain accessible. 

See Also: 

■ Oracle Database Advanced Replication for more information about 
Oracle Database replication features 

■ Oracle Streams Concepts and Administration for information 
about Oracle Streams, another method of sharing information 
betvi'een databases 

Heterogeneous Distributed Database Systems 

In a heterogeneous distributed database system, at least one of the databases is a 
non-Oracle Database svstem. To the application, the heterogeneous distributed 
database svstem appears as a single, local, Oracle Database, The local Oracle Database 
server hides the distribution and heterogeneity of the data. 

The Oracle Database server accesses the non-Oracle Database svstem using Oracle 
Heterogeneous Services in conjunction with an agent. If you access the non-Oracle 
Database data store using an Oracle Transparent Gateway, then the agent is a 
svstem -specific application. For example, if you include a Svbase database in an Oracle 
Database distributed system, then vou need to obtain a Svbase- specific transparent 
gateway so that the Oracle Database in the system can communicate with it. 

Alternatively, you can use generic connectivity to access non-Oracle Database data 
stores so long as the non-Oracle Database system supports the ODBC or OLE DB 
protocols. 
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Note: Other than the introductory material presented in this 
chapter, tliis book does not discuss Oracle Heterogeneous Services. 
See Oracle Database Hcierogencoiis Coiimctii'ilij AdminisfraSor's Guide 
for more detailed information about Heterogeneous Services. 



Heterogeneous Services 

Heterogeneous Services (HS) is an integrated component within the Oracle Database 
server and the enabling technologv for the current suite of Oracle Transparent 
Gatewav products, HS provides the common architecture and administration 
mechanisms for Oracle Database gateway products and other heterogeneous access 
facilities. Also, it provides upwardlv compatible functionalit\' for users of most of the 
earlier Oracle Transparent Gateway releases. 

Transparent Gateway Agents 

For each non-Oracle Database system that voll access, Heterogeneous Services can use 
a transparent gateway agent to interface with the specified non-Oracle Database 
system. The agent is specific to the non-Oracle Database system, so each type of 
system requires a different agent. 

The transparent gateway agent facilitates communication between Oracle Database 
and non-Oracle Database svstems and uses the Heterogeneous Services component in 
the Oracle Database server The agent executes SQL and transactional requests at the 
non-Oracle Database svstem on behalf of the Oracle Database server 

See Also: Your Oracle- supplied gatewav- specific documentation 
for information about transparent gateways 

Generic Connectivity 

Generic connectivity enables vou to connect to non-Oracle Database data stores by 
using either a Heterogeneous Services ODBC agent or a Heterogeneous Services OLE 
DB agent Both are included with your Oracle product as a standard feature. Any data 
source compatible with the ODBC or OLE DB standards can be accessed using a 
generic connectivit}" agent. 

The advantage to generic connectivit}' is that it may not be required for vou to 
purchase and configure a separate sv stem-specific agent. You use an ODBC or OLE 
DB driver that can interface with the agent However, some data iiccess features are 
onlv available with transparent gateivay agents. 



Client/Server Database Architecture 



A database server is the Oracle software managing a database, and a client is an 
application that requests information from a server Each computer in a netivork is a 
node that can host one or more databases. Each node in a distributed database system 
can act as a client, a ser\'er, or both, depending on the situation. 

In Figure 29—2, the host for the hq database is acting as a database server when a 
statement is issued against its local data (for example, the second statement in each 
transaction issues a statement against the local dept table), but is acting as a client 
when it issues a statement against remote data (for example, the first statement in each 
transaction is issued against the remote table emp in the sales database). 
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Figure 29-2 An Oracle Database Distributed Database System 
Server Server 




DEPT Table 



Application 



TRANSACTION 



INSERT IKTO EMPSSaLES . 
DELETE FROM DEPT. . ; 



SELECT . . . 

FROM EHPeSSLES . . . ; 



COMMIT; 



A client can connect directly or indirectly to a database server. A direct connection 
occurs when a client connects to a ser\'er and accesses information from a database 
contained on that server. For example, if vou connect to the hq database and access the 
dept table on this database as in Figure 29-2, you can issue the following: 

SELECT ' FROM dept; 

This query is direct because you are not accessing an object on a remote database. 

In contrast, an indirect connection occurs vi'hen a client connects to a server and then 
accesses information contained in a database on a different server For example, if you 
connect to the hq database but access the emp table on the remote sales database as 
in Figure 29—2, you can issue the following: 

SELECT ' FROM empOsales; 

This query is indirect because the object you are accessing is not on the database to 
which vou are directly connected. 



Database Links 



The central concept in distributed database systems is a database link. A database link 
is a connection between two physical database servers that allows a chent to access 
them as one logical database. 

This section contains the following topics: 

■ What Are Database Links? 

■ Whv Use Database Links? 
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Global Database Names in Database Links 

Names for Database Links 

Tvpes of Database Links 

Users of Database Links 

Creation of Database Links: Examples 

Schema Objects and Database Links 

Database Link Restrictions 



What Are Database Links? 



A database link is a pointer that defines a one-wav communication path from an 
Oracle Database server to another database server. The link pointer is actually defined 
as an entry in a data dictionary table. To access the link, you must be connected to the 
local database that contains the data dictionary entr}'. 

A database link connection is one-way in the sense that a client connected to local 
database A can use a link stored in database A to access information in remote 
database B, but users connected to database B cannot use the same link to access data 
in database A. If local users on database B want to access data on database A, then 
they must define a link that is stored in the data dictionar\' of database B. 

A database link connection allows local users to access data on a remote database. For 
this connection to occur, each database in the distributed svstem must have a unique 
global database name in the neb,vork domain. The global database name uniquely 
identifies a database server in a distributed system. 

Figure 29-3 shows an example of user scott accessing the emp table on the remote 
database with the global name hq . acme . com: 



Figure 29-3 [^tabase Link 
User Scott 



M 



Select * 
FROM emp 




PUBLIC SYHONYM 

eirp -> empBHQ .ACHE .COH 
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Database links are either private or public. If they are private, then only the user who 
created the link has access; if they are public, then all database users have access. 

One principal difference among database links is the way that connections to a remote 
database occur. Users access a remote database through the following types of links: 



Type of Link 



Description 



Connected user link 



Fixed user link 



Users connect ss themselves, which means that they must have an 
account on the remote database with the same username as their 
account on the local database. 

Users connect using the username and password referenced in the 
hnk. For example, if Jane uses a fixed user link that connects to the 
hq database with the username and password scott/tiger, then 
she connects as scott, Jane has all the privileges in hq granted to 
scott directly, and all the default roles that scott has been 
granted in the hq database. 



Current user link A user connects as a global user. A local user can connect as a 

global user in the context of a stored procedure, without storing 
the global user's password in a link definition. For example, Jane 
can access a procedure that Scott wrote, accessing Scotts account 
and Scott's schema on the hq database. Current user links are an 
aspect of Oracle Advanced Security 



Create database links using the CREATE DATABASE LINK statement. After a link is 
created, vou can use it to specify schema objects in SQL statements. 

See Also: 

■ Oracle Database SQL Language Reference for svntax of the 

CREATE DATABASE statement 

■ Oracle Database Advanced Security Administrator's Guide for 
information about Oracle Advanced Security 



What Are Shared Database Links? 



A shared database link is a link between a local server process and the remote 
database. The link is shared because multiple client processes can use the same link 
simultaneously. 

When a local database is connected to a remote database through a database link, 
either database can run in dedicated or shared server mode. The following table 
illustrates the possibilities: 



Local Database Mode 


Remote Database Mode 


Dedicated 


Dedicated 


Dedicated 


Shared server 


Shared server 


Dedicated 


Shared server 


Shared server 



A shared database link can exist in any of these four configurations. Shared links differ 
from standard database links in the following wavs: 

■ Different users accessing the same schema object through a database link can 
share a network connection. 
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When a user needs to establish a connection to a remote server from a particular 
server process, the process can reuse connections already established to the remote 
server. The reuse of the connection can occur if the connection was established on 
the same server process with the same database link, possibly in a different 
session. In a non-shared database link, a connection is not shared across multiple 
sessions. 

When vou use a shared database link in a shared server configuration, a network 
connection is established directly out of the shared server process in the local 
server. For a non-shared database link on a local shared server, this connection 
would have been established through the local dispatcher, requiring context 
switches for the local dispatcher, and requiring data to go throitgh the dispatcher. 

See Also: Oracle Database Nef Services Administrator's Guide for 
information about shared server 



Why Use Database Links? 



The great advantage of database links is that thev allow users to access another user's 
objects in a remote database so that thev are bounded hv the pri\'ilege set of the object 
owner In other words, a local user can access a link to a remote datiibase without 
having to be a user on the remote database. 

For example, assume that emplovees submit expense reports to Accounts Pavable 
(A/P). and further suppose that a user using an A/P application needs to retrieve 
information about emplovees from the hq database. The A/P users should be able to 
connect to the hq database and execute a stored procedure in the remote hq database 
that retrieves the desired information. The A/P users should not need to behq 
database users to do their jobs; they should only he able to access hq information in a 
controlled wav as limited bv the procedure. 

See Also: 

■ "Users of Database Links" on page 29-11 for an explanation of 
database link users 

■ "Viewing Information About Database Links" for an 
explanation of how to hide passwords from non-administrative 
users 



Global Database Names in Database Links 



To understand how a database link works, vou must first understand what a global 
database name is. Each database in a distributed database is uniquely identified by its 
global database name. The database forms a global database name by prefixing the 
database network domain, specified by the DB_DOMAIN initialization parameter at 
database creation, with the individual database name, specified by the DB_NAME 
initialization parameter 

For example. Figure 29-^ illustrates a representative hierarchical arrangement of 
databases throughout a network. 
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Figure 29-4 Hierarchical Arrangement of Networked Databases 
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COM 



Educalional 
Institutions 
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ACME TOOLS 



DfViSiONl 
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DiViSiON3 




ZZ\ZK 



ASIA 



AMERICAS 



Employees (HR) 



HO Finance Sales mfg 



JAPAN 



US 



EUROPE 



MEXICO 



UK 



GERMANY 




The name of a database is formed by starting at the leaf of the tree and following a 
path to the root. For example, the mfg database is in divisions of the acme_toolE 
branch of the com domain. The global database name for mfg is created by 
concatenating the nodes in the tree as follows; 

■ mf g . divi si on 3 . acme_tool s . com 

While several databases can share an individual name, each database must have a 
unique global database name. For example, the network domains 

us . amer icas . acme_auto . com and uk . europe . acme_auto . com each contain a 
sales database. The global database naming system distinguishes the sales 
database in the americas division from the sales database in the europe division 
as foilow^s: 

■ sales. us. americas . acme_auto . com 

■ sales.uk. europe . acme_auto . com 

See Also: "Managing Global Names in a Distributed Svstem" on 
page 30-1 to learn how to specify and change global database 



Names for Database Links 



Typically, a database hnk has the same name as the global database name of the 
remote database that it references. For example, if the global database name of a 
database is sales .us .oracle, com, then the database link is also called 

sales .us . oracle . com. 

When you set the initialization parameter GLOBAL_NAMES to TRUE, the database 
ensures that the name of the database link is the same as the global database name of 
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the remote database. For example, if the global database name for hq is 

hq . acme . com, and GLOBAL_NMIES is TRUE, then the link name must be called 

hq . acme . com. Note that the database checks the domain part of the global database 

name as stored in the data dictionary, not the DB_DOMAIN setting in the initialization 

parameter file (see "Changing the Domain in a Global Database Name" on page 30-3). 

If you set the initialization parameter GLOBAL_SAMES to FALSE, then you are not 
required to use global naming. You can then name the database link whatever you 
want. For example, vou can name a database link to hq .acme .com as f oo. 



Note: Oracle recommends that vou use global naming because 
many useful features, including Replication, require global naming. 

After vou have enabled global naming, database links are essentiallv transparent to 
users of a distributed database because the name of a database link is the same as the 
global name of the database to which the link points. For example, the following 
statement creates a database link in the local database to remote database sales: 

CEEaTE PUBLIC DATABASE LINK sales.division3.acme.com USING 'salesl'r 

See Also: Oracle Database Reference for more information about 
specifying the initialization parameter GLOBAL_NAMES 



Types of Database Links 



Oracle Database lets you create private, public, and global database links. These basic 
link types differ according to which users are allowed access to the remote database: 



Type 



Owner 



Description 



Private User who created the link. 

View ownership data 
. through: 

I ■ DBA_DB_LIHKS 

■ ALL_DB_LINKS 

■ USER DB LIHKS 



Creates link in a specific schema of the local 
database. Only the owner of a private database 
hnk or PL /SQL subprograms in the schema can 
use this link to access database objects in the 
corresponding remote database. 



Public User called PUBLIC. View 

ownership data through 
views shown for private 
database links. 



Creates a database-wide link. All users and 
PL /SQL subprograms in the database can use 
the link to access database objects in the 
corresponding remote database. 



Global User called PUBLIC. View 

ownership data through 
views shown for private 
database links. 



Creates a netis'ork-wide link. When an Oracle 
network uses a directory server, the directory 
server automatically create and manages global 
database links (as net service names) for every 
Oracle Database in the network. Users and 
PL /SQL subprograms in any database can use 
a global link to access objects in the 
corresponding remote database. 

Note: In earlier releases of Oracle Database, a 
global database link referred to a database link 
that was registered with an Oracle Names 
server The use of an Oracle Names server has 
been deprecated. In this document, global 
database links refer to the use of net service 
names from the directorv server. 
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Deterininmg the t\'pe of database links to emplov in a distributed dat.ibase depends 
on the specific requirements of the apphcations using the system. Consider these 
features when making your choice: 



Type of Link 



Features 



Private database link 



Public database link 



Global database link 



This link is more secure than a public or global link, because 
onlv the owner of the private hnk, or subprograms within the 
same schema, can use the link to access the remote database. 

When many users require 3lI\ access path to a remote Oracle 
Database, you can create a single public database link for all 
users in a database. 

When an Oracle network uses a directory server, an 
administrator can conveniently manage global database links 
for all databases in the system. Database link management is 
centralized and simple. 



See Also: 



"Specifying Link Types" on page 30-7 to learn how to create 
different types of database links 

"Viewing Information About Database Links" on page 30-16 to 
learn how to access information about links 



Users of Database Links 



When creating the link, vou determine which user should connect to the remote 
database to access the data. The following table explains the differences among the 
categories of users involved in database links; 



User Type 



Description 



Sample Link 
Creation Syntax 



Connected user A local user accessing a database link in which no fixed username 
and password have been specified. If SYSTEM accesses a public link 
in a query, then the connected user is SYSTEM, and the database 
I connects to the SYSTEM schema in the remote database. 

Note; A connected user does not have to be the user who created the 
link, but is any user who is accessing the link. 



CREATE PUBLIC 
DATABASE LIHK hq 
USIHG 'hq' ; 



Current user A global user in a CURREHTJSER database link. The global user 

must be authenticated by an X.509 certificate (an SSL-authenticated 
enterprise user) or a password [a password-authenticated enterprise 
user), and be a user on both databases involved in the link. Current 
user links are an aspect of the Oracle Advanced Security option. 

See Oracle Dntnfcasc Aiivancfd Security Admitusttctor's Guide for 
information about global security 



CREATE PUBLIC 
DATABASE LIHK hq 
CONNECT TO 
CURREHT_USER 
using ' hq ' ; 



Fixed user A user whose username /password is part of the link definition. If a 

link includes a fixed user, the fixed user's username and password 
. are used to connect to the remote database. 



CREATE PUBLIC 
DATABASE LIHK hq 
CONNECT TO jane 
IDENTIFIED BY 
doe USING ' hq ' ; 



See Also: "Specifying Link Users" on page 30-8 to learn how to 
specifv users when creating links 
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Connected User Database Links 

Connected user links have no connect string associated with them. The advantage of a 
connected user link is that a user referencing the link connects to the remote database 
as the same user, and credentials don't have to be stored in the link definition in the 
data dictionarv. 

Connected user links have some disadvantages. Because these links require users to 
have accounts and privileges on the remote databases to which thev are attempting to 
connect, they require more privilege administration for administrators. Also, giving 
users more privileges than thev need violates the fundamental securit\' concept of 
least privilege: users should only be given the privileges they need to perform their 
jobs. 

The abilitv to use a connected user database link depends on several factors, chief 
among them whether the user is authenticated by the database using a password, or 
externally authenticated bv the operating system or a network authentication service. 
If the user is externally authenticated, then the ability to use a connected user link also 
depends on whether the remote database accepts remote authentication of users, 
which is set by theREMOTE_OS_AUTHENT initialization parameter. 

The REMOTE_OS_AUTHENT parameter operates as follows: 

REMOTE_OS_AUTHENT 

Value Consequences 



TRUE for the remote database An externally- authenticated user can connect to the 

remote database using a connected user database link. 



FALSE for the remote database An externally- authenticated user cannot connect to the 

remote database using a connected user database link 
unless a secure protocol or a network authentication 
service supported by the Oracle Advanced Security 
option is used. 



Note: The REM0TE_OS_AUTHENT initialization parameter is 
deprecated. It is retained for backward compatibility only. 



Fixed User Database Links 

A benefit of a fixed user link is that it connects a user in a primary database to a 
remote database with the securit}' context of the user specified in the connect string. 
For example, local user j oe can create a public database link in j oe's schema that 
specifies the fixed user scott with password tigsr. If jane uses the fixed user link 
in a quer}', then j ane is the user on the local database, but she connects to the remote 
database as scott/ tiger. 

Fixed user links have a username and password associated with the connect string. 
The username and password are stored with other link information in data dictionary 
tables. 

Current User Database Links 

Current user database links make use of a global user. A global user must be 
authenticated by an X.509 certificate or a password, and be a user on both databases 
involved in the link. 

The user invoking the CURRBNT_USER link does not have to be a global user. For 
example, if jane is authenticated (not as a global user) by password to the Accounts 
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Payable database, she can access a stored procedure to retrieve data from the hq 
database. The procedure uses a current user database link, which connects her to hq as 
global user scott . User scott is a global user and authenticated through a 
certificate over SSL, hut j ane is not. 

Note that current user database links have these consequences: 

■ If the current user database link is not accessed from vi'ithin a stored object, then 
the current user is the same as the connected user accessing the link. For example, 
if scott issues a SELECT statement through a current user hnk, then the current 
user is scott. 

■ When executing a stored object such as a procedure, view, or trigger that accesses 
a database link, the current user is the user that owns the stored object, and not the 
user that cfl//s the object. For example, if jane calls procedure scott .p (created 
by scott), and a current user link appears ivithiii the called procedure, then 
scott is the current user of the link. 

■ If the stored object is an invoker-rights function, procedure, or package, then the 
invoker's authorization ID is used to connect as a remote user For example, if user 
jane calls procedure scott .p (an invoker-rights procedure created by scott), 
and the link appears inside procedure scott . p, then j ane is the current user, 

■ You cannot connect to a database as an enterprise user and then use a current user 
link in a stored procedure that exists in a shared, global schema. For example, if 
user jane accesses a stored procedure in the shared schema guest on database 
hq, she cannot use a current user link in this schema to log on to a remote 
database. 

See Also: 

■ "Distributed Database Securitv" on page 29-17 for more 
information about security issues relating to database links 

■ Oracle Database Advanced Security Administrator's Guide 

■ Oracle Database PL/SQL Language Reference for more information 
about invoker-rights functions, procedures, or packages. 



Creation of Database Links: Examples 



Create database links using the CREATE DATABASE LINK statement. The table gives 
examples of SQL statements that create database links in a local database to the reniote 

sales .us . americas . acme auto . com database: 



SOL Statement 



Connects To Database Connects As 



Link Type 



CREATE DATABASE LIHK 
sales .us . americas . acme_auto . co 
|m USING 'sales us ' ; 



sales using net service Connected user 
name sales us 



Private 

connected 

user 



CREATE DATABASE LIHK foo 
CONNECT TO CURHENT_USER USItJG 
' ain_s Is'; 



sales using service 
name am sis 



Current globijl user 



Private 
current user 



CREATE DATABASE LIHK 
sales .us . americas . acme_auto . co 
m COHHECT TO scott IDENTIFIED 
BY tiger USING 'sales_us'; 



sales using net service scott using pijssvvord 
name sales_us tiger 



Private fixed 
user 
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SOL Statement 


Connects To Database 


Connects As 


Link Type 


CREATE PUBLIC DATABASE LINK 


sales using net service 


scott using password 


Public fixed 


sales CONNECT TO scott 


name rev 


tiger 


user 


IDENTIFIED BY tiger USIHG 
' rev ' ; 








CREATE SHARED PUBLIC DATABASE 


sales using net service 


scott using password 


Shared 


LINK 


name sales 


tiger, authenticated as 


pubhc fixed 


sales .us -americas . acme auto . co 




anupam using password 


user 


m COHHECT TO scott IDENTIFIED 




bhide 




BY tiger AUTHENTICATED BY 








anupam IDENTIFIED BY bhide 








USING 'sales' ,- 









See Also: 



"Creating Database Links" on page 30-6 to learn how to create 
link 

Orack' Database SQL Language Reference for information about 
the CREATE DATABASE LIHK statement syntax 



Schema Objects and Database Links 



After vou have created a database link, vou can execute SQL statements that access 
objects on the remote database. For example, to access remote object emp using 
database link f oo, you can issue: 

SELECT ' FROM empSfoo; 

You must also be authorized in the remote database to access specific remote objects. 

Constructing properlv formed object names using database hnks is an essential aspect 
of data manipulation in distributed systems. 

Naming of Schema Objects Using Database Linl(s 

Oracle Database uses the global database name to name the schema objects globally 
using the following scheme: 

schema . schsma._object@gloha.l_da.ta.ha.se_name 

where: 

■ schema is a collection of logical structures of data, or schema objects. A schema is 
owned bv a database user and has the same name as that user. Each user owns a 
single schema, 

■ schem3._ohject is a logical data structure like a table, index, view, synonym, 
procedure, package, or a database link. 

■ gloh3.1_da.ta.hase_naine is the name that uniquelv identifies a remote database. 
This name must be the same as the concatenation of the remote database 
initialization parameters DB_NAME and DB_DOMAIN, unless the parameter 
GLOBAL_NAMES is set to FALSE, in which case any name is acceptable. 

For example, using a database link to database sales .divisions . acme . com, a user 
or application can reference remote data as follows: 

SELECT ' FROM scott.erap@3ales.diviEion3.acme.com; # emp table in scott's schema 
SELECT loc FROM scott.deptSsales.diviEion3.acme.com; 
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If GLOBAL_NAMES is set to FALSE, then vou can use any name for the Hnk to 
sales . divisions . acme . com. For example, you can call the link f oo. Then, you 
can access the remote database as follows: 

SELECT name ITiOH scott.empefoo; tt link name different from global name 

Authorization for Accessing Remote Sciiema Objects 

To access a remote schema object, vou must be granted access to the remote object in 
the remote database. Further, to perform anv updates, inserts, or deletes on the remote 
object, you must be granted the SELECT privilege on the object, along with the 
UPDATE, INSERT, or DELETE privilege. Unlike when accessing a local object, the 
SELECT privilege is necessarv for accessing a remote object because the database has 
no remote describe capabilit\'. The database must do a SELECT ' on the remote object 
in order to determine its structure. 

Synonyms for Sciiema Objects 

Oracle Database lets vou create synonvms so that vou can hide the database link name 
from the user A svnonvm allows access to a table on a remote database using the 
same syntax that you would use to access a table on a local database. For example, 
assume you issue the following query against a table in a remote database: 

SELECT ' FROM einp@hq.acme.com; 

You can create the svnonvm emp for emp@hq . acme . com so that vou can issue the 
following query instead to access the same data: 

SELECT ' FROM emp; 

See Also: "Using Svnonvms to Create Location Transparency" on 
page 30-20 to learn how to create synonvms for objects specified 
using database links 

Schema Object Name Resolution 

To resolve application references to schema objects (a process called name resolution), 
the database forms object names hier archie allv. For example, the database guarantees 
that each schema within a database has a unique name, and that within a schema each 
object has a unique name. As a result, a schema object name is always unique within 
the database. Furthermore, the database resolves application references to the local 
name of the object. 

In a distributed database, a schema object such as a table is accessible to all 
applications in the svstem. The database extends the hierarchical naming model with 
global database names to effectively create global object names and resolve references 
to the schema objects in a distributed database svstem. For example, a quen' can 
reference a remote table by specifving its fully qualified name, including the database 
in which it resides. 

For example, assume that you connect to the local database as user SYSTEM: 

COHHECT SYSTEMOsalesl 

You then issue the following statements using database link hq . acme . com to access 
objects in the scott and jane schemas on remote database hq: 

SELECT ' FROM scott.emp@hq.acme.com; 

INSEIRT IHTO jane.accounts@hg.acme.com {acc_no, acc_name, balance) 

VALUES (5001, 'BOWER', 2000); 
"UPDATE jane.accoim.ts@hg.acme.com 
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SET balance = balance + 500; 
DELETE FROM jane.account3@hq.acme.com 
MHEHE acc_name = 'BOWER'; 

Database Link Restrictions 

You cannot perform the following operations using database links: 

■ Grant privileges on remote objects 

■ Execute DESCRIBE operations on some remote objects. The following iem.ote 
objects, however, do support DESCRIBE operations: 

- Tables 

- View^s 

- Procedures 

- Functions 

■ Analyze remote objects 

■ Define or enforce referential integritv 

■ Grant roles to users in a remote database 

■ Obtain nondefault roles on a remote database. For example, if j a.ne connects to 
the local database and executes a stored procedure that uses a fixed user link 
connecting as scott, jane receives scott's default roles on the remote database. 
Jane cannot issue SET ROLE to obtain a nondefault role. 

■ Execute hash query joins that use shared server connections 

■ Use a current user link without authentication through SSL, password, or NT 
native authentication 

Distributed Database Administration 

The following sections explain some of the topics relating to database management in 
an Oracle Database distributed database system: 

■ Site Autonomy 

■ Distributed Database Security 

■ Auditing Database Links 

■ Administration Tools 

See Also: 

■ Chapter 30, "Managing a Distributed Database" to learn how to 
administer homogenous systems 

■ Oracle Database Heterogeneous Connectivity Administrator's Guide 
to learn about heterogeneous services concepts 



Site Autonomy 



Site autonomy means that each server participating in a distributed database is 
administered independentlv from all other databases. Although several databases can 
work together, each database is a separate repository of data that is managed 
individuallv. Some of the benefits of site autonomv in an Oracle Database distributed 
database include: 
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■ Nodes of the system can mirror the logical orgiinization of companies or groups 
that need to maintain independence. 

■ Local administrators control corresponding local data. Therefore, each database 
administrator's domain of responsibility is smaller and more manageable, 

■ Independent failures are less likely to disrupt other nodes of the distributed 
database. No single database failure need halt all distributed operations or be a 
performance bottleneck. 

■ Administrators can recover from isolated system failures independently from, 
other nodes in the system, 

■ A data dictionary exists for each local database. A global catalog is not necessarv 
to access local data. 

■ Nodes can upgrade software independently. 

Although Oracle Database permits you to manage each database in a distributed 
database system independently, you should not ignore the global requirements of the 
system. For example, you mav need to: 

■ Create additional user accounts in each database to support the hnks that you 
create to facilitate server- to -ser\'er connections, 

■ Set additional initialization parameters such as COMMIT_POINT_STRENGTH, and 

OPEW_LIWKS, 



Distributed Database Security 



The database supports all of the security features that are available with a 

no n- distributed database environment for distributed database systems, including: 

■ Password authentication for users and roles 

■ Some types of external authentication for users and roles including: 

- Kerberos version 5 for connected user links 

- DCE for connected user links 

■ Login packet encr\'ption for client- to- server and server-to- server connections 

The following sections explain some additional topics to consider when configuring an 
Oracle Database distributed database system: 

Authentication Through Database Links 

Authentication Without Passwords 

Supporting User Accounts and Roles 

Centralized User and Privilege Management 

Data Encryption 

See Also: Oracle Database Advanced Security Administrator's Guide 
for more information about external authentication 

Authentication Through Database Links 

Database links are either private or public, authenticated or non-authenticated. You 
create public links by specifying the PUBLIC keyword in the link creation statement. 
For example, you can issue: 

CREATE PUBLIC DATABASE LINK f oo USIHG ' sales ' ; 
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You create authenticated links by specifying the CONNECT TO clause, 
AUTHENTICATED BY clause, or both clauses together in the database link creation 
statement. For example, you can issue: 

CPEATE DATABASE LIHK sales CONNECT TO scott IDENTIFIED BY tiger D3IHG 'sales'; 
CREATE SHARED PUBLIC DATABASE LINK sales CONNECT TO nick IDENTIFIED BY firesign 
AUTHENTICATED BY david IDENTIFIED BY bowie USING 'sales'; 

This table describes how users access the remote database through the link: 



Link Type Authenticated Security Access i 


Private 


No When connecting to the remote database, the database 

uses security information [use rid/password) taken from 
the local session. Hence, the link is a connected user 
database link. Passwords must be synchronized between | 
the two databases. 


Private 


Yes The use rid /password is taken from the link definition 

rather than from the local session context Hence, the link 
is a fixed user database link. 

This configuration allows passwords to be different on the 
two databases, but the local database link password must 
match the remote database password. 


Public 


No Works the same as a private nonauthenticated link, except 
that all users can reference this pointer to the remote 
database. 


Public 


Yes All users on the local database can access the remote 

database and all use the same userid /password to make 
the connection. , 



Authentication Without Passwords 

When using a connected user or current user database link, you can use an external 
authentication source such as Kerberos to obtain end-to-end security. In end-to-end 
authentication, credentials are passed from server to server and can be authenticated 
bv a database server belonging to the same domain. For example, if j ane is 
authenticated externally on a local database, and wants to use a connected user link to 
connect as herself to a remote database, the local server passes the security ticket to the 
remote database. 

Supporting User Accounts and Roies 

In a distributed database system, you must carefully plan the user accounts and roles 
that are necessary to support applications using the system. Note that: 

■ The user accounts necessary to establish server- to -server connections must be 
available in all databases of the distributed database system. 

■ The roles necessar}' to make available application privileges to distributed 
database application users must be present in all databases of the distributed 
database svstem. 

As you create the database links for the nodes in a distributed database svstem, 
determine which user accounts and roles each site needs to support server- to- server 
connections that use the links. 

In a distributed environment, users tvpically require access to many network services. 
When you must configure separate authentications for each user to access each 
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network service, security' administration can become unwieldy, especially for large 
systems. 

See Also: "Creating Database Links" on page 30-6 for more 
information about the user accounts that must be available to 
support different Kpes of database links in the system 

Centralized User and Privilege Management 

The database provides different ways for vou to manage the users and privileges 
involved in a distributed system. For example, vou have these options: 

■ Enterprise user management. You can create global users who are authenticated 
through SSL or bv using passwords, then manage these users and their privileges 
in a directory through an independent enterprise directory service. 

■ Network authentication service. This common technique simplifies security 
management for distributed environments. You can use the Oracle Advanced 
Securit}" option to enhance Oracle Net and the security of an Oracle Database 
distributed database system. Windows NT native authentication is an example of 
a non-Oracle authentication solution. 

See Also: 

■ Oracle Database Advanced Security Administrator' i Guide 

■ Oracle Database Enterprise User Security Administrator's Guide 

Schema-Dependent Global Users One option for centralizing user and privilege 
management is to create the following: 

■ A global user in a centralized directory 

■ A user in every database that the global user must connect to 

For example, you can create a global user called f red with the following SQL 
statement: 

CREATE OSER fred IDENTIFIED GLOBAIiY AS 'CN=fred adains, 0=Oracle,C=England' ; 

This solution allows a single global user to be authenticated by a centralized directory. 

The schema -de pendent global user solution has the consequence that vou must create 
a user called fred on everv database that this user must access. Because most users 
need permission to access an application schema but do not need their own schemas, 
the creation of a separate account in each database for ever\' global user creates 
significant overhead. Because of this problem, the database also supports 
schema-independent users, which are global users that an access a single, generic 
schema ineverv database. 

Schema-Independent Global Users The database supports functionality that allows a 
global user to be centrally managed by an enterprise directory ser\'ice. Users who are 
managed in the directory are called enterprise users. This directory contains 
information about: 

■ Which databases in a distributed system, an enterprise user can access 

■ Which role on each database an enterprise user can use 

■ Which schema on each database an enterprise user can connect to 

The administrator of each database is not required to create a global user account for 
each enterprise user on each database to which the enterprise user needs to connect. 
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Instead, multiple enterprise users can connect to tlie same database scliema, called a 
shared schema. 



Note: You cannot access a current user database link in a shared 
schema. 



For example, suppose jane, bill, and acott all use a human resources application, 
Thehq application objects are all contained in the guest schema on thehq database. 
In this case, you can create a local global user account to be used as a shared schema. 
This global username, that is, shared schema name, is guest, jane, bill, and scott 
are all created as enterprise users in the directory service. Thev are also mapped to the 
guest schema in the director}', and can be assigned different authorizations in the hg 
application. 

Figure 29-5 illustrates an example of global user security using the enterprise 
directory service: 



Figure 29-5 Global User Security 




SSL I password 



Assume that the enterprise directory service contains the following information on 
enterprise users for hg and sales: 



Database 


Role 


Schema 


Enterprise Users 


tb 


clerkl 


guest 


bill 
scott 


sales 


clerk2 


guest 


j ane 
scott 



Also, assume that the local administrators for hq and sales have Issued statements as 
follows: 



Database CREATE Statements 



hq 



CREATE DSER guest IDEHTIFIE3) GLOBALLY AS ' ' ; 

CREATE ROLE clerkl GRANT select ON emp; 

CREATE PUBLIC DATABASE LINK sales_link CONMECT fiS CUERENTJSES 

USING 'sales'; 
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Database CREATE Statements 



sales CREATE USER guest IDENTIFIED GLOBALLY AS 

CREATE ROLE clerk2 GRANT select ON dept; 



Assume that enterprise user scott requests a connection to local database liq in order 
to execute a distributed transaction involving sales. The following steps occur (not 
necessarily in this exact order): 

1. Enterprise user scott is authenticated using SSL or a password. 

2. User scott issues the following statement: 

SELECT e.ename, d.loc 

EROM emp e, dept@sales_lirik d 

l-fflERE e . deptno=d . deptno ; 

3. Databases hq and sales mutuallv authenticate one another using SSL, 

4. Database hq queries the enterprise directory service to determine whether 
enterprise user scott has access to hq, and discovers scott can access local 
schema guest using role clerkl. 

5. Database sales queries the enterprise directory service to determine whether 
enterprise user scott has access to sales, and discovers scott can access local 
schema guest using role clerk2. 

6. Enterprise user scott logs into sales to schema guest with role clerk2 and 
issues a SELECT to obtain the required information and transfer it to hq. 

7. Database hq receives the requested data from sales and returns it to the client 

scott. 

See Also: Oracle Database Enterprise User Security Adminisfralor's 
Guide for more information about enterprise user securit}' 

Data Encryption 

The Oracle Advanced Security option also enables Oracle Net and related products to 
use network data encryption and checksumming so that data cannot be read or 
altered. It protects data from unauthorized viewing by using the RSA Data Security 
RC4 or the Data Encryption Standard (DES) encryption algorithm. 

To ensure that data has not been modified, deleted, or replayed during transmission, 
the securit}' services of the Oracle Advanced Security option can generate a 
crypto graphically secure message digest and include it with each packet sent across 
the network. 

See Also: Oracle Database Advanced Security Administrator's Guide 
for more information about these and other features of the Oracle 
Advanced Security option 



Auditing Database Links 



You must always perform auditing operations locally. That is, if a user acts in a local 
database and accesses a remote database through a database link, the local actions are 
audited in the local database, and the remote actions are audited in the remote 
database, provided appropriate audit options are set in the respective databases. 
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The remote database cannot determine whether a successful connect request and 
subsequent SQL statements come from another server or from a locally connected 
client. For example, assume the following: 

■ Fixed user link hq . acme . com connects local user j ane to the remote hq database 
as remote user scott . 

■ User scott is tiudited on the remote database. 

Actions performed during the remote database session are audited as if scott were 
connected locally to hq and performing the same actions there. You must set audit 
options in the remote database to capture the actions of the username— in this case, 
scott on the hq database— embedded in the link if the desired effect is to audit what 
j ane is doing in the remote database. 



Note: You can audit the global username for global users. 



You canjiot set local auditing options on remote objects. Therefore, vou cannot audit 
use of a database link, although access to remote objects can be audited on the remote 
database. 



Administration Tools 



The database administrator has several choices for tools to use when managing an 
Oracle Database distributed database system: 

■ Enterprise Manager 

■ Third-Part}' Administration Tools 
. SNMP Support 

Enterprise Manager 

Enterprise Manager is the Oracle Database administration tool that provides a 
graphical user interface (GUI). Enterprise Manager provides administrative 
functionalit\' for distributed databases through an easv-to-use interface. You can use 
Enterprise Manager to: 

■ Administer multiple databases. You can use Enterprise Manager to administer a 
single database or to simultaneously administer multiple databases. 

■ Centralize database administration tasks. You can administer both local and 
remote databases running on any Oracle Database platform in any location 
worldwide. In addition, these Oracle Database platforms can be connected by any 
network protocols supported bv Oracle Net. 

■ Dynamically execute SQL, PL/SQL, and Enterprise Manager commands. You can 
use Enterprise Manager to enter, edit, and execute statements. Enterprise Manager 
also maintains a history of statements executed. 

Thus, you can reexecute statements without retyping them, a particularly useful 
feature if you need to execute lengthy statements repeatedly in a distributed 
database system. 

■ Manage security features such as global users, global roles, and the enterprise 
directory service. 
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Third-Party Administration Toois 

Ciirrentlv more than 60 companies produce more than 150 products that help manage 
Oracle Databases and networks, providing a truly open environment. 

SNMP Support 

Besides its network administration capabilities, Oracle Simple Network Management 
Protocol [SNMP) support allows an Oracle Database server to be located and queried 
by any SNMP-based network management system, SNMP is the accepted standard 
underlying many popular network management systems such as: 

HP OpenView 

Digital POLYCENTER Manager on NetView 

IBMNetView/6000 

Novell NetWare Management System 

SunSoft SunNet Manager 



Transaction Processing in a Distributed System 



A transaction is a logical unit of work constituted bv one or more SQL statements 
executed by a single user A transaction begins with the user's first executable SQL 
statement and ends when it is committed or rolled back bv that user 

A remote Iransaction contains onlv statements that access a single remote node. A 
distributed transaction contains statements that access more than one node. 

The following sections define important concepts in transaction processing and 
explain how transactions access data in a distributed database: 

Remote SQL Statements 

Distributed SQL Statements 

Shared SQL for Remote and Distributed Statements 

Remote Transactions 

Distributed Transactions 

Two-Phase Commit Mechanism 

Database Link Name Resolution 

Schema Object Name Resolution 



Remote SQL Statements 



A remote query statement is a quen' that selects information from one or more remote 
tables, all of which reside at the same remote node. For example, the following query 
accesses data from the dept table in the scott schema of the remote sales database: 

SELECT ' FROM scott .deptSsales .us .americas .aciiie_auto.com; 

A remote update statement is an update that modifies data in one or more tables, all of 
which are located at the same remote node. For example, the following query updates 
the dept table in the scott schema of the remote sales database: 

UPDATE scott . deptSmktrig . us .amsrioas .acme_auto.com 
SET loc = 'MEW YORK' 
WHERE deptno = 10; 
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Note: A remote update can include a subquery that retrieves data 
from one or more remote nodes, but because the update happens at 
only a single remote node, the statement is classified as a remote 
update. 



Distributed SQL Statements 

A distributed query statement retrieves information from two or more nodes. For 
example, the following query accesses data from the local database as well as the 
remote sales database: 

SELECT enanie, dnaine 

FROM scott.erap e, scott.dept@sales.us.a1nerica3.acrae_auto.com d 
WHERE e.deptno = d.deptno; 

A distributed update statement modifies data on tivo or more nodes, A distributed 
update is possible using a PL/SQL subprogram unit such as a procedure or trigger 
that includes two or more remote updates that access data on different nodes. For 
example, the following PL/SQL program unit updates tables on the local database and 
the remote sales database: 

BEGIH 

UPDATE scott.deptSsales .us .americas .acrae_auto.com 
SET loc = 'NEW YORK' 
WHERE deptno = 10; 
UPDATE scott.emp 
SET deptno = 11 
WHERE deptno = 10; 
END; 
COMMIT; 

The database sends statements in the program to the remote nodes, and their 
execution succeeds or fails as a unit. 

Shared SQL for Remote and Distributed Statements 

The mechanics of a remote or distributed statement using shared SQL are essentially 
the same as those of a local statement. The SQL text must match, and the referenced 
objects must match. If available, shared SQL areas can be used for the local and remote 
handling of any statement or decomposed query. 

See Also: Oracle Database Concepts for more information about 
shared SQL 



Remote Transactions 



A remote transaction contains one or more remote statements, all of which reference a 
single remote node. For example, the following transaction contains two statements, 
each of which accesses the remote sales database: 

UPDATE Ecott . deptSsales . us . americas . acme_auto . cora 

SET loc = 'HEW YORK' 

WHERE deptno = 10; 
UPDATE scott .erapSsales .us .americas.acme_auto.com 

SET deptno = 11 

WHERE deptno = 10; 
COMMIT; 
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Distributed Transactions 



A distribiited. transaction is a transaction that includes one or more statements that, 
individuallv or as a group, update data on two or more distinct nodes oi a distributed 
database. For example, this transaction updates the local database and the rem.ote 
sales database: 

UPDATE Ecott .deptSsales .UE.americas.acme_auto.com 

SET loc = 'HEW YORK' 

WHERE deptno = 10; 
UPDATE scott.emp 

SET deptno = 11 

WHERE deptno = 10; 
COMMIT,- 



Note: If all statements of a transaction reference only a single 
remote node, the transaction is remote, not distributed. 



Two-Phase Commit Mechanism 



A database must guarantee that all statements in a transaction, distributed or 
non-distributed, either commit or roll back as a unit. The effects of an ongoing 
transaction should be invisible to all other transactions at all nodes; this transparency 
should be true for transactions that include anv type of operation, including queries, 
updates, or remote procedure calls. 

The general mechanisms of transaction control in a non-distributed database are 
discussed in the Oracle Database Concepts. In a distributed database, the database must 
coordinate transaction control with the same characteristics over a network and 
maintain data consistency, even if a network or system failure occurs. 

The database two-phase commit mechanism guarantees that all database servers 
participating in a distributed transaction either all commit or all roll back the 
statements in the transaction, A two-phase commit mechanism also protects implicit 
DML operations performed by integrity constraints, remote procedure calls, and 
triggers. 

See Also: Chapter 32, "Distributed Transactions Concepts" for 
more information about the Oracle Database two-phase commit 
mechanism 



Database Link Name Resolution 



A global object name is an object specified using a database link. The essential 
components of a global object name are: 

■ Object name 

■ Database name 

■ Domain 

The following table shows the components of an explicitly specified global database 
object name: 

Statement Object Database Domain 



SELECT * FROM dept sales acme.com 

joan. deptSsales .acme .com 
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Statement Object Database Domain 



SELECT ' FROM emp 

empSmktg . us .acme .com 



mktg us.acme.com 



Whenever a SQL statement includes a reference to a global object name, the database 
searches for a database link with a name that matches the database name specified in 
the global object name. For example, if you issue the following statement: 

SELECT ' FROM Ecott.erap@orderE.-UE.acme.com; 

The database searches for a database link called orders .us . acme . com. The database 
performs this operation to determine the path to the specified remote database. 

The database always searches for matching database links in the following order: 

1. Private database links in the schema of the user who issued the SQL statement. 

2. Public database links in the local database. 

3. Global database links (only if a directory server is available). 

Name Resolution When the Global Database Name Is Complete 

Assume that you issue the following SQL statement, which specifies a complete global 
database name: 

SELECT ' FROM emp@prodl.UE.oracle.com; 

In this case, both the database name (prodl) and domain components 
(us . oracle . com) are specified, so the database searches for private, public, and 
global database links. The database searches onlv for links that match the specified 
global database name. 

Name Resolution When the Global Database Name Is Partial 

If any part of the domain is specified, the database assumes that a complete global 
database name is specified. If a SQL statement specifies a partial global database name 
(that is, only the database component is specified), the database appends the value in 
the DB_D0M6.IN initialization parameter to the value in the DB_NAME initialization 
parameter to construct a complete name. For example, assume you issue the following 
statements: 

COMNECT scott@locdb 

SELECT ' FROM Ecott ,erap@orderE ; 

If the network domain for locdb is ue . acme . com, then the database appends this 
domain to orders to construct the complete global database name of 
orders .us . acme . com. The database searches for database links that match only the 
constructed global name. If a matching link is not found, the database returns an error 
and the SQL statement cannot execute. 

Name Resolution When No Global Database Name Is Specified 

If a global object name references an object in the local database and a database link 
name is )iof specified using the @ symbol, then the database automaticallv detects that 
the object is local and does not search for or use database links to resolve the object 
reference. For example, assume that you issue the following statements: 

COHMECT soott@locdb 
SELECT ' from ECott,erap; 
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Because the second statement does not specify a global database name using a 
database link connect string, the database does not search for database links. 

Terininating the Search for Name Resolution 

The database does not necessarily stop searching for matching database links when it 
finds the first match. The database must search for matching private, public, and 
network database links until it determines a complete path to the remote database 
(both a remote account and service name). 

The first match determines the remote schema as illustrated in the following table: 



User Operation 

Do not specifj' the 

CONNECT clause 

Do specify the 
CONHECT TO . . . 
IDENTIFIED BY 
clause 



Database Response Example 



Uses a connected user CREATE DATABASE LIHK kl USIHG 



database link 

Uses a fixed user 
database link 



' prod' 

CREATE DATABASE LIHK k2 
CONNECT TO scott IDENTIFIED BY 
tiger USIHG 'prod' 



Specify the COMMECT 

TO ajRRENT_USER 
clause 

Do not specify the 

USING clause 



Uses a current user 
database link 



Searches until it finds a 
link specifying a 
database string. If 
matching database 
links are found and a 
string is never 
identified, the database 
returns an error 



CREATE DATABASE LIHK k3 

CONNECT TO CDRRENTJSER USIHG 
' prod ' 

CREATE DATABASE LIHK k4 
CONNECT TO CURRENT USER 



After the database determines a complete path, it creates a remote session, assuming 
that an identical connection is not already open on behalf of the same local session. If a 
session alreadv exists, the database reuses it 



Schema Object Name Resolution 



After the local Oracle Database connects to the specified remote database on behalf of 
the local user that issued the SQL statement, object resolution continues as if the 
remote user had issued the associated SQL statement. The first match determines the 
remote schema according to the following rules: 



Type of Link Specified 



Location of Object Resolution 



A fixed user database link 



Schema specified in the link creation statement 



A connected user database link 



Connected user's remote schema 



, A current user database link 



Current user's schema 



If the database cannot find the object, then it checks public objects of the remote 
database. If it cannot resolve the object, then the established remote session remains 
but the SQL statement cannot execute and returns an error. 

The following are examples of global object name resolution in a distributed database 
svstem. For all the following examples, assume that: 
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Example of Global Object Name Resolution: Complete Object Name 

This example illustrates how the database resolves a complete global object nam.e and 
determines the appropriate path to the remote database using both a private and 
public database link. For this example, assume the following: 

■ The remote database is named sales .divisions . acme . com. 

■ The local database is named hq. divisions . acme . com. 

■ A directory server (and therefore, global database links) is not available. 

■ A remote table emp is contained in the schema t smith. 
Consider the following statements issued bv scott at the local database: 

COHMECT scottehq 

C3?EATE PUBLIC DATABASE LINK sales.dlvlsion3.acme.com 
CONNECT TO guest IDENTIFIED BY network 
USING 'dbstring' ; 

Later, JWARD connects and issues the following statements: 

COHMECT jwardehq 

CREATE DATABASE LINK sales.divlslon3.acme.com 
CONNECT TO tsmlth IDENTIFIED BY radio; 

UPDATE tsmlth. empSsales .divisions .acme.com 
SET deptno =40 
WHERE deptno = 10; 

The database processes the final statement as follows: 

1. The database determines that a complete global object name is referenced in 

j ward's UPDATE statement. Therefore, the svstem begins searching in the local 
database for a database link with a matching name. 

2. The database finds a matching private database link in the schema jward. 
Nevertheless, the private database link jward . sales .divisions . acme . com 
does not indicate a complete path to the remote sales database, only a remote 
account. Therefore, the database now searches for a matching public database link, 

3. The database finds the public database link in scott's schema. From this public 
database link, the database takes the service name dbstrlng, 

4. Combined with the remote account taken from the matching private fixed user 
database link, the database determines a complete path and proceeds to establish a 
connection to the remote sales database as user tsmith/radio. 

5. The remote database can now resoh'e the object reference to the emp table. The 
database searches in the tsmlth schema and finds the referenced emp table. 

6. The remote database completes the execution of the statement and returns the 
results to the local database. 

Example of Global Object Name Resolution: Partial Object Name 

This example illustrates how the database resolves a partial global object name and 
determines the appropriate path to the remote database using both a private and 
public database link. 

For this example, assume that: 
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■ The remote database is named sales .divisions . acme . com. 

■ The local database is named hq. d.ivision3 . acme . com. 

■ A directory ser\'er (and therefore, global database links) is not available, 

■ A table emp on the remote database sales is contained in the schema tsmith, 
but not in schema scott. 

■ A public synonym named emp resides at remote database sales and points to 
tsmith. emp in the remote database sales, 

■ Thepubhc database link in "Example of Global Object Name Resolution: Complete 
Object Name" on page 29-28 is already created on local database hq: 

CREATE PUBLIC DATABASE LINK sales.division3.acme.com 
COHMECT TO guest IDENTIFIED BY network 
USING 'dhstring' ; 

Consider the following statements issued at local database hq: 

COIHECT scottehq 

CREATE DATABASE LINK sales.division3.acme.com; 

DELETE FROM empSsales 
WHERE empno = 4299; 

The database processes the final DELETE statement as follows: 

1. The database notices that a partial global object name is referenced in scott's 
DELETE statement. It expands it to a complete global object name using the 
domain of the local database as follows: 

DELETE FROM empSsales .divisions .acme. com 
MHEHE empno = 4299; 

2. The database searches the local database for a database link with a matching 
name, 

3. The database finds a matching pr/'wati' connected user link in the schema scott, 
but the private database link indicates no path at all. The database uses the 
connected username /password as the remote ace oimt portion of the path and then 
searches for and finds a matching public database link: 

CREATE PUBLIC DATABASE LINK sales. division3 , acme. com 
COHNECT TO guest IDENTIFIED BY network 
USING 'dhstring' ; 

4. The database takes the database net sen'ice name dbstring from the public 
database link. At this point, the database has determined a complete path, 

5. The database connects to the remote database as scott/ tiger and searches for 
and does not find an object named emp in the schema scott, 

6. The remote database searches for a public synonym named emp and finds it, 

7. The remote database executes the statement and returns the results to the local 
database. 

Global Name Resolution in Views, Synonyms, and Procedures 

A view, synonym, or PL/SQL program unit (for example, a procedure, function, or 
trigger) can reference a remote schema object by its global object name. If the global 
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object name is complete, then the database stores the definition of the object without 
expanding the global object name. If the name is partial, howe\'er, the database 
expands the name using the domain of the local database name. 

The following table explains when the database completes the expansion of a partial 
global object name for views, synonvms, and program units: 



User Operation 



Database Response 



Creiite s view 



Does not expand piirtial global names. The data dictionary 
stores the exact text of the defining query Instead, the database 
expands a partial global object name each time a statement that 
uses the view is parsed. 



Create a synonym Expands partial global names. The definition of the synonym 

stored in the data dictionary includes the expanded global 
object name. 



Compile a program unit Expands partial global names. 



What Happens When Global Names Change 

Global name changes can affect views, synonyms, and procedures that reference 
remote data using partial global object names. If the global name of the referenced 
database changes, views and procedures mav try to reference a nonexistent or 
incorrect database. On the other hand, synonyms do not expand database link names 
at runtime, so they do not change. 

Scenarios for Global Name Changes 

For example, consider two databases named sales . uk . acme . com and 

hq.uk. acme . com. Also, assume that the sales database contains the following view 

and synonym: 

CliEATE Vim employee_names A3 

SELECT ename FROM scott .empShr ; 

CliEATE SYMOHYM employee FOR scott.emp@hr; 

The database expands the employee synonym definition and stores it as: 

scott . empShr . uk . acme . com 

Scenario 1: Botli Databases Change Names First, consider the situation where both the 
Sales and Human Resources departments are relocated to the United States. 
Consequently, the corresponding global database names are both changed as follows: 

■ sales.uk. acme . com becomes sales .us . acme . com 

■ hq . uk . acme . com becomes hq . us . acme . com 

The following table describes query expansion before and after the change in global 



Query on sales Expansion Before Change 



Expansion After Change 



SELECT ' FROM SELECT ' FROM SELECT ' FROM 

emploYee_naine3 scott .erapShr .uk.acme .com scott .emp@hr .us .acme .com 



SELECT ' FROM 
employee 



SELECT ' FROM SELECT ' FROM 

scott .empShr .uk.acme . com scott .empShr .uk.acme . com 
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Scenario 2: One Database Changes Names Now consider that only the Sales department is 
moved to the United States; Human Resources remains in the UK. Consequently, the 
corresponding global database names are both changed as follows: 

■ sales . uk . acme . com becomes sales .us . acme . com 

■ hq . uk . acme . com is not changed 

The following table describes querv expansion before and after the change in global 
n.imes: 

Query on sales Expansion Before Change Expansion After Change 

SELECT * FROM SELECT * FROM SELECT ' FROM j 

emploYee_iiames scott .empShr .uk.acme .com scott .empOhr .us .acme .com 

SELECT ' FROM SELECT ' FROM SELECT ' FROM 

employee scott .emp@hr .uk.acme.com scott .emp@hr .uk.acme.com 



In this case, the defining querv of the emploYee_names view expands to a 
nonexistent global database name. On the other hand, the employee synonym 
continues to reference the correct database, hq . uk . acme . com. 

Distributed Database Application Development 

Application development in a distributed system raises issues that are not applicable 
in a n on- distributed system. This section contains the follovi'ing topics relevant for 
distributed application development: 

■ Transparency in a Distributed Database System 

■ Rem.ote Procedure Calls (RPCs) 

■ Distributed Query Optimization 

See Also: Chapter 31, "Developing Applications for a Distributed 
Database System" to learn how to develop applications for 
distributed systems 

Transparency in a Distributed Database System 

With minimal effort, vou can develop apphcations that make an Oracle Database 
distributed database svstem transparent to users that work with the system. The goal 
of transparency is to make a distributed database svstem appear as though it is a 
single Oracle Database. Consequently, the system does not burden developers and 
users of the system with complexities that would otherwise make distributed database 
apphcation development challenging and detract from user productivity. 

The following sections explain more about transparency in a disfributed database 
system. 

Location Transparency 

An Oracle Database distributed database system has features that allow application 
developers and administrators to hide the physical location of database objects from 
applications and users. Location transparency exists when a user can universally refer 
to a database object such as a table, regardless of the node to which an application 
corm.ects. Location transparency has several benefits, including: 
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■ Access to remote data is simple, because database users do not need to know the 
physical location of database objects. 

■ Administrators can move database objects with no impact on end-users or existing 
database applications. 

Tvpically, administrators and developers use svnonyms to establish location 
transparency for the tables and supporting objects in an application schema. For 
example, the following statements create svnonyms in a database for tables in another, 
remote database. 

CPEATE PUBLIC SYMOHYM emp 

FOE Ecott.empSsales .us .ainericas.acme_auto.com; 
CPEATE PUBLIC SYMONYM dept 

FOE scott.deptSsales .us .americas.acme_auto.com; 

Now, rather than access the remote tables with a quer}' such as: 

SELECT ename, dname 

FROM scott.emp@sales.us.americas.acme_auto.com e, 
scott .deptSsales .us .americas . acme_auto . com d 
WHERE e.deptno = d.deptno; 

An application can issue a much simpler query that does not have to account for the 
location of the remote tables. 

SELECT ename, dname 
FROM emp e, dept d 
MHERE e.deptno = d.deptno; 

In addition to svnonyms, developers can also use views and stored procedures to 
establish location transparency for applications that work in a distributed database 
svstem. 

SQL and COMMIT Transparency 

The Oracle Database distributed database architecture also provides query, update, 
and transaction transparency. For example, standard SQL statements such as SELECT, 
INSERT, UPDATE, and DELETE work just as they do in a non-distributed database 
environment. Additionally, applications control transactions using the standard SQL 
statements COMMIT, SAVEPOINT, and ROLLBACK, There is no requirement for complex 
programming or other special operations to provide distributed transaction control, 

■ The statements in a single transaction can reference any number of local or remote 
tables, 

■ The database guarantees that all nodes involved in a distributed transaction take 
the same action; they either all commit or all roll back the transaction. 

■ If a network or svstem failure occurs during the commit of a distributed 
transaction, the transaction is automatically and transparently resolved globally. 
Specifically, when the network or system is restored, the nodes either all commit 
or all roll back the transaction. 

Internal to the database, each committed transaction has an associated system change 
number (SCN) to uniquely identify the changes made bv the statements within that 
transaction. In a distributed database, the SCNs of communicating nodes are 
coordinated when: 

■ A connection is established using the path described by one or more database 
links. 
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■ A distributed SQL statement is executed, 

■ A distributed transaction is committed. 

Among other benefits, the coordination of SCNs among the nodes of a distributed 
database svstem allows global distributed re ad -consistency at both the statement and 
transaction level. If necessary, global distributed time-based recovery can also be 
completed. 

Replication Transparency 

The database also provide many features to transparently replicate data among the 
nodes of the system. For more information about Oracle Database replication features, 

see Oracle Database Advanced Repliattion. 



Remote Procedure Calls (RPCs) 



Developers can code PL/SQL packages and procedures to support applications that 
work with a distributed database. Applications can make local procedure calls to 
perform work at the local database and remote procedure calls (RPCs) to perform 
work at a remote database. 

When a program calls a remote procedure, the local server passes all procedure 
parameters to the remote server in the call. For example, the following PL /SQL 
program unit calls the packaged procedure del_emp located at the remote sales 
database and passes it the parameter 1257: 

BEGIH 

emp_mgmb.del_en^@sales ."us.aniericas.acme_auto.coiii[1257) ; 
EHD; 

In order for the RPC to succeed, the called procedure must exist at the remote site, and 
the user being connected to must have the proper privileges to execute the procedure. 

When developing packages and procedures for distributed database systems, 
developers must code with an understanding of what program units should do at 
remote locations, and how to return the results to a calling application. 



Distributed Query Optimization 



Distributed query optimization is an Oracle Database feature that reduces the 
amount of data transfer required beti\'een sites when a transaction retrieves data from 
remote tables referenced in a distributed SQL statement. 

Distributed query optimization uses cost-based optimization to find or generate SQL 
expressions that extract onlv the necessary data from remote tables, process that data 
at a remote site or sometimes at the local site, and send the results to the local site for 
final processing. This operation reduces the amount of required data transfer when 
compared to the time it takes to transfer all the table data to the local site for 
processing. 

Using various cost-based optimizer hints such as DRIVING_SITE, NO_MERGE, and 
INDEX, you can control where Oracle Database processes the data and how it accesses 
the data. 

See Also: "Using Cost-Based Optimization" on page 31-3 for more 
information about cost-based optimization 
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Character Set Support for Distributed Environments 

Oracle Database supports environments in which clients, Oracle Database servers, and 
non-Oracle Database servers use different character sets. WCHAR support is provided 
for heterogeneous environments. You can set a variety of National Language Support 
(NLS) and Heterogeneous Seri'ices (HS) environment variables and initialization 
parameters to control data conversion between different character sets. 

Character settings are defined by the following NLS and HS param.eters: 



Parameters 


Environment 


Defined For 


MLS LANG 


Client-Server 


Client 


(environment variiible) 






HLS_LANGUAGE 


Client-Server 


Oracle Database server 


MLSJHAEACTERSET 


Not Heterogeneous Distributed 




m,S_TERRITORY 


HeterogeneousDistributed 




HS_LAHGUAGE 


Heterogeneous Distributed 


Non-Oracle Database 

server 

Transparent gateway 


HLSJCHAR 


Heterogeneous Distributed 


Oracle Database server 


{environment variiible) 




Transparent gateway 


hs_nls_nc:har 







See Also: 



Oracle Database Giobatizaiion Support Guide for information 
about NLS parameters 

Oracle Database Heterogeneous Connectivity Administrator's Guide 
for information about HS parameters 



Client/Server Environment 



In a client/server environment, set the client character set to be the same as or a subset 
of the Oracle Database server character set, as illustrated in Figure 29—6. 

Figure 29-6 NLS Parameter Settings in a Client/Server Environment 



n 



I 



^ 



- NLS_LANG = 
NLS settings of 
Oracle server or 
subset ol rl 



Oracle 
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Homogeneous Distributed Environment 



In a non-heterogeneous environment, the client and server character sets should be 
either the same as or subsets of the main server character set, as illustrated in 
Figure 29-7: 

Figure 29-7 NLS Parameter Settings in a Homogeneous Environment 




■ NLS setting similar or 
subset of the other 
Oracle server 



NLS_LANG = 

NLS settings of Oracle 

server{s) or subEet{s) 
o1 II 



Heterogeneous Distributed Environment 



In a heterogeneous environment, the globalization support parameter settings of the 
client, the transparent gateway, and the non-Oracle Database data source should be 
either the same or a subset of the database server character set as illustrated in 
Figure 29-8. Transparent gateways have full globalization support. 

Figure 29-8 NL S Parameter Settings in a Heterogeneous Environment 



NLS settings lo be the 
same or the subset 
of Oracle server 
NLS setting 




NLS_LANG = 

NLS settings of Oracle 

server or subset of it 
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In a heterogeneous environment, only transparent gateways built with HS technology 
support complete NCHAR capabilities. Whether a specific transparent gateway 
supports NCHAR depends on the non-Oracle Database data source it is targeting. For 
information on how a particular transparent gateway handles NCHAR support, consult 
the system -specific transparent gateway documentation. 

See Also: Oracle Database Heterogeneous Conneci'roity 
Adininhirator's Guide for more detailed information about 
Heterogeneous Services 
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Managing a Distributed Database 



In this chapter: 

Managing Global Names in a Distributed System 

Creating Database Links 

Using Shared Database Links 

Managing Database Links 

Viewing Information About Database Links 

Creating Location Transparency 

Managing Statement Transparency 

Managing a Distributed Database: Examples 



Managing Global Names in a Distributed System 

In a distributed database system, each database should have a unique global database 
name. Global database names uniquelv identify' a database in the system, A primarv 
administration task in a distributed svstem is managing the creation and alteration of 
global database names. 

This section contains the following topics: 

Understanding How Global Database Names Are Formed 

Determining Whether Global Naming Is Enforced 

Viewing a Global Database Name 

Changing the Domain in a Global Database Name 

Changing a Global Database Name: Scenario 



Understanding How Global Database Names Are Formed 

A global database name is formed from two components: a database name and a 
domain. The database name and the domain name are determined by the foUowing 
initialization parameters at database creation: 



Component Parameter Requirements 



Example 



Database name DB HAME 



Must be eight characters or less. 



sales 
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Component Parameter Requirements Example 

Domain DB_DOMa.IN' Must follow standard Internet us . acme .com 

containing the conventions. Levels in domain names 

database must be separated by dots and the i 

' order of domain names is from leaf to | 

root, left to right. 



These are examples of valid global database names: 



DB_NAME 


DB_DOMAIN 


Global Database Name 


sales 


au . oracle . com 


sales .au. oracle . com 


sales 


us .oracle . com 


sales .us . oracle . com 


mktg 


us -oracle. com 


mktg. us -oracle . com 


payroll 


nonprofit . org 


payroll -nonprofit. org 



The DB_DOMAIN initialization parameter is only important at datiihase creation time 
when it is used, together with the DB_NAME parameter, to form the database global 
name. At this point, the database global name is stored in the data dictionary. You 
must change the global name using an ALTER DATABASE statement, not bv altering 
the DB_DOMAIN parameter in the initialization parameter file. It is good practice, 
however, to change the DB_DOMAIN parameter to reflect the change in the domain 
name before the next database startup. 

Determining Whether Global Naming Is Enforced 

The name that you give to a link on the local database depends on whether the remote 
database thatvou want to access enforces global naming. If the remote database 
enforces global naming, then vou must use the remote database global database name 
as the name of the link. For example, if vou are connected to the local hq ser\'er and 
want to create a link to the remote mfg database, and mf g enforces global naming, 
then you must use themf g global database name as the link name. 

You can also use service names as part of the database link name. For example, if I'ou 
use the ser\'ice names snl and En2 to connect to database hq. acme - com, and hq 
enforces global naming, then vou can create the following link names to hq: 

■ HQ.aCME.COMeSNl 

■ H2.aCME.COM@SN2 



See Also: "Using Connection Qualifiers to Specify Service Names 
Within Link Names" on page 30-10 for more information about 
using services names in link names 



To determine whether global naming on a database is enforced on a database, either 
examine the database initialization parameter file or quer)' the VS PARAMETER view. 
For example, to see whether global naming is enforced onmf g, you could start a 
session onmf g and then create and execute the following globalnames . sql script 
(sample output included): 

COL HAME FORMAT A12 
COL VALUE FORMAT A6 
SELECT HAME, VALUE FROM VSPAHAHETER 
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WHERE MME = ' global_naines ' 
/ 

SQL> Sglobalnames 

NME VALUE 

global_nameE FALSE 



Viewing a Global Database Name 



Use the data dictionary view GLOBAL_WAME to view the database global name. For 
example, issue the following: 

SELECT ' FROM GLOBAL_MME,- 

GLOBAL_HME 

SALES . AU . ORACLE . COM 

Changing the Domain in a Global Database Name 

Use the ALTER DATABASE statement to change the domain in a database global name. 
Note that after the database is created, changing the initialization parameter 
DB_DOMAIN has no effect on the global database name or on the resolution of database 
link names. 

The following example shows the syntax for the renaming statement, where database is 
a database name and domain is the network domain: 

ALTER DATABASE RENAI'lE GL0BAL_HAI>1E TO database. domain; 

Use the following procedure to change the domain in a global database name: 
1 . Determine the current global database name. For example, issue: 

SELECT ' FROM GLOBAL_HAME; 

GLOBAL_NAME 

SALES . AU . ORACLE . COM 



2. Rename the global database name using an ALTER DATABASE statement. For 
example, enter: 

ALTER DATABASE RENAME GLOBAL_HAME TO sales .us. oracle. com; 

3. Quer}' the GLOBAL_NAME table to check the new name. For example, enter: 

SELECT ' FROM GLOBAL_HAME; 
GLOBAL_NAME 

SALES . US . ORACLE . COM 

Changing a Global Database Name: Scenario 

In this scenario, you change the domain part of the global database name of the local 
database. You also create database links using partiallv specified global names to test 
how Oracle Database resolves the names. You discover that the database resolves the 
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partial names using the domain part of the current global database name of the local 
database, not the value for the initialization parameter DB_D0M6.IN, 

1. You connect to SALES.US.ACME.COM and query the GLOBAL_WAME data 
dictionary view to determine the current database global name: 

COHNECT SYSTEM@Eales.us.acme.com 
SELECT ' FROM GLOBAL_HAME; 

GLOBAL_HME 

SALBS.US.ACHE.COM 



2. You quer}' the VSPARAMETER view to determine the current setting for the 
DB_DOMAIN initialization parameter: 

SELECT HAME, VALUE FROM VSPARAMETER WHERE MAME = 'db_doraain'r 
HAME VALUE 

dl>_domain DS . ACME . COM 

3. You then create a database link to a database called hq, using only a 
partially-specified global name: 

CREATE DATABASE LINK hq USIHG 'sales'; 

The database expands the global database name for this link by appending the 
domain part of the global database name of the local database to the name of the 
database specified in the link, 

4. You query USER_DB_LIWKS to determine which domain name the database uses 
to resolve the partially specified global database name: 

SELECT DB_LIHK FROM USER_DB_LINKS ; 

DB_LINK 

HQ.US.ACME.COM 

This result indicates that the domain part of the global database name of the local 
database is us . acme . com. The database uses this domain in resolving partial 
database link names when the database link is created. 

5. Because you have received word that the sales database will move to Japan, you 
rename the sales database to sales . jp . acme . com: 

ALTER DATABASE RENAME GLOBAL_HME TO sales.jp.acme.com; 
SELECT ' FROM GLOBAL_HME; 

GLOBAL_NAME 

SALES.JP.ACME.COM 

6. You query VSPARAMETER again and discover that the value of DB_DOMAIH is not 
changed, although you renamed the domain part of the global database name: 

SELECT HAME, VALUE FROM VSPARAMETER 
WHERE HAME = ' dl)_domain ' ; 

HAME VALUE 

db domain US.AQIE.COM 
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This result indicates that the value of the DB_DOMAIN initiahzation parameter is 
independent of the ALTER DATABASE RENAME GLOBAL_NAME statement. The 
ALTER DATABASE statement determines the domain of the global database name, 
not the DB_DOMAIN initialization parameter (although it is good practice to alter 
DB_DOMAIN to reflect the new domain name). 

7. You create another database link to database supply, and then query 

USER_DB_LINKS to see how the database resolves the domain part of the global 
database name of supply: 

CREATE DATABASE LIHK supply USIMG 'supply'; 
SELECT DE_LINK FROM USER_DB_LINKS ; 

DB LINK 



HQ.US.ACME.COM 
SUPPLY.JP.ACME.COM 



This result indicates that the database resolves the partiallv specified link name by 
using the domain jp . acme .com. This domain is used when the link is created 
because it is the domain part of the global database name of the local database. 
The database does no! use the DB_DOMAIN initialization parameter setting when 
resolving the partial link name, 

8. You then receive word that your previous information was faultv: sales will be 
in the ASIA . JP . ACME . COM domain, not the JP . ACME . COM domain. 
Consequently, vou rename the global database name as follows; 

ALTER DATABASE RENAME GLOBAL_NAME TO sales .asia . jp .acme. com; 
SELECT ' FROM GLOBAL_HAME; 

GLOBAL_HAME 

SALES.ASIA.JP.ACME.COM 

9. You query VS PARAMETER to again check the setting for the parameter 

DB_DOMAIN: 

SELECT HAME, VALTIE FROM VS PARAMETER 

WHERE HAME = ' db_domain ' ; 

HAME VALUE 

db_domain US . ACME . COM 

The result indicates that the domain setting in the parameter file is exactiv the 
same as it was before you issued t'/Y/ifr of the ALTER DATABASE REHAME 
statements. 

10. Finally, you create a link to the warehouse database and again query 
USER_DB_LINKS to determine how the database resolves the partially-specified 
global name: 

CREATE DATABASE LIHK warehouse USIHG 'warehouse'; 
SELECT DB_LIHK FROM USER_DB_LIHKS ; 

DB LINK 



HQ.US.ACME.COM 
SUPPLY.JP.ACME.COM 
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WAREHOUSE . ASIA . JP . ACME . COM 

Again, vou see that the database uses the domain part of the global database name 
of tiie local database to expand the partial link nanae during link creation. 

Note: In order to correct the supply database link, it must be 
dropped and re-cieated. 



See Also: Oracle Database Rejeivnce for more information about 
specifying the DB_NAME and DB_DOMAIN initialization parameters 



Creating Database Links 

To support apphcation access to the data and schema objects throughout a distributed 
database svstem, you must create all necessarv database links. This section contains 
the following topics: 

■ Obtaining Privileges Necessary for Creating Database Links 

■ Specifying Link Tvpes 

■ Specifying Link Users 

■ Using Connection Qualifiers to Specif;' Service Names Within Link Names 

Obtaining Privileges Necessary for Creating Database Links 

A database link is a pointer in the local database that lets vou access objects on a 
remote database. To create a private database link, vou must have been granted the 
proper privileges. The following table illustrates which privileges are required on 
which database for which t\'pe of link: 

Privilege Database Required For 

CREATE DATABASE LIHK Local Creation of a private database link. 



CREATE PDBLIC DATABASE LINK Local Creation of a public database link. 



CREATE SESSION Remote Creation of any type of database link. 



To see which privileges vou currentlv have available, query ROLE_SYS_PRIVS, For 
example, you could create and execute the following privs . sql script {sample 
output included); 

SELECT DISTIHCT PRIVILEGE AS "Database Link Privileges" 

EROM ROLE_S¥S_PRIVS 

WHERE PRIVILEGE IH { 'CREATE SESSIOH' ,' CREATE DATABASE LINK', 

'CREATE PDBLIC DATABASE LIHK' ) 
/ 

SQL> Oprivs 

Database Link Privileges 



CREATE DATABASE LINK 
CREATE PUBLIC DATABASE LINK 
CREATE SESSIOH 
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Specifying Linl< Types 



When you create a database link, vou must decide who will have access to it. The 
following sections describe how to create the three basic types of links: 

■ Creating Private Database Links 

■ Creating Public Database Links 

■ Creating Global Database Links 

Creating Private Database Links 

To create a pri\'ate database link, specify the following (where Unk_naiuc is the global 
database name or an arbitrary link name): 

atEA'FE DATABASE LINK link_name . . . ; 

Following are examples of private database links: 



SOL Statement 



Result 



CREATE DATABASE LIHK 
supply . us . acme . com; 



A privdte link using the global database name to the 
remote supply database. 

The link uses the userid/piissword of the connected 
user. So if scott (identified by tiger) uses the 
hnk in a query, the Unk estabhshes a connection to 

the remote databiise as scott/ tiger. 



CREATE DATABASE LIHK link._2 
CONNECT TO jane IDEHTIFIED 
BY doe USIHG ' us_supply ' ; 



A private fixed user Unk called hnk_2 to the 
database with service name us_supply. The Unk 

connects to the remote database with the 
userid /password of jane /doe regardless of the 
connected user. 



CREATE DATABASE LIHK link_l 
CONHECT TO CDHHENTJSER 
USING ' us_supply ' ; 



A private link called link_l to the database with 

service name us_Eupply. The link uses the 

use rid /password of the current user to log onto the 

remote database. 

Note: T!ie current user may not be the same as the 
connected user, and must be a global user on both 
databases involved in the link (see "Users of 
Database Links" on page 29-11). Current user links 
are part of the Oracle Advanced Security option. 



See Also: Oracle Database SQL Language Reference for CREATE 

DATABASE LINK syntax 

Creating Public Database Linlts 

To create a public database link, use the ke^Tvord PUBLIC (where Imkjiiame is the 
global database name or an arbitrary link name): 

CREATE PUBLIC DATABASE LINK Iiiijt_iianie ...; 

Follow^ing are examples of public database links: 
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SOL Statement 



Result 



CREATE PDBLIC DATABASE LINK 
supply . us . acme . com; 



A public link to the remote supply database. 
The link uses the userid /password of the 

connected user. So if scott (identified by 
tiger) uses the link in a query, the link 
establishes a connection to the remote database 

as scott/tiger. 



CREATE PUBLIC DATABASE LINK 

pu_link COHNECT TO 
CURREHT_USER DSING 'supply'; 



CREATE PUBLIC DATABASE LINK 
sales.us.acme.com CONNECT TO 
jane IDENTIFIED BY doe; 



A public link called pu_linkto the database 
with service name supply. The link uses the 

userid/password of the current user to log 
onto the remote database. 

Note: The current user may not be the same as 
the connected user, and must be a global user 
on both databases involved in the link (see 
"Users of Database Links" on page 29-11). 

A public fixed user link to the remote sales 
database. The link connects to the remote 
database with the userid/password of 
j ane/doe. 



See Also: Oiack Database SQL Language Reference for CREATE 

PUBLIC DATABASE LINK syntax 

Creating Global Database Links 

In earlier releases, you defined global database links in the Oracle Names server The 
Oracle Names server has been deprecated. Now, vou can use a director\' server in 
which databases are identified bv net sen,' ice names. In this document these are what 
are referred to as global database links. 

See the Oracle Database Net Services Administrator's Guide to learn how to create 
directorv entries that act as global database iinJ(s, 



Specifying Linl( Users 



A database link defines a communication path from one database to another. When an 
application uses a database link to access a remote database, Oracle Database 
establishes a database session in the remote database on behalf of the local application 
request. 

When you create a private or public database link, you can determine which schema 
on the remote database the link will establish connections to by creating fixed user, 
current user, and connected user database links. 

Creating Fixed User Database Links 

To create a fixed user database link, you embed the credentials (in this case, a 
username and password) required to access the remote database in the definition of 
the link: 

CREATE DATABASE LINK . . , COHHECT TO username IDENTIFIED BY passivord . , . ; 

Following are examples of fixed user database links: 
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SOL Statement Result 



CREATE PUBLIC DATABASE LIMK A publiclink using the global database name to the 
supply.ua . acme . com CONNECT remote supply database. The hnk connects to the 
TO scott AS tiger; remote database with the userid/password 

scott/ tiger. 

CREATE DATABASE LINK foo A private fixed user hnk called foo to the database 

CONNECT TO jane IDENTIFIED with service name finance. The Hnk connects to 
BY doe USING 'finance'; the remote database with the userid/password 

j ane / doe. 



When an application uses a fixed user database link, the local server always 
establishes a connection to a fixed remote schema in the remote database. The local 
server also sends the fixed user's credentials across the network when an application 
uses the link to access the remote database. 

Creating Connected User and Current User Database Links 

Connected user and current user database links do not include credentials in the 
definition of the link. The credentials used to connect to the remote database can 
change depending on the user that references the database link and the operation 
performed by the application. 

Note: For many distributed applications, you do not want a user 
to have privileges in a remote database. One simple wav to achieve 
this result is to create a procedure that contains a fixed user or 
current user database link within it. In this way, the user accessing 
the procedure temporarily assumes someone else's privileges. 



For an extended conceptual discussion of the distinction between connected users and 
current users, see "Users of Database Links" on page 29-11. 

Creating a Connected User Database Linl< To create a connected user database link, omit 
the CONNECT TO clause. The following syntax creates a connected user database link, 
where dblink is the name of the link and net_servicc_iiamc is an optional connect string: 

CREATE [SHARED] [PUBLIC] DATABASE LINK dblink ... [USING ' net_service_ndme' ] : 

For example, to create a connected user database link, use the following syntax: 

CREATE DATABASE LINK saIeE.division3.acme.com USING 'sales' ; 

Creating a Current User Database Link To create a current user database link, use the 
CONNECT TO CURRENT_USER clause in the hnk creation statement Current user 
hnks are only available through the Oracle Advanced Securitv option. 

The following syntax creates a current user database link, where dbVmk is the name of 
the hnk and net_servicc_nttmc is an optional connect string: 

CREATE [SHARED] [PUBLIC] DATABASE LINK dblink CONNECT TO CURRENT_USER 
[USING 'net_service_naine' ] ; 

For example, to create a connected user database link to the sales database, you 
might use the following syntax: 

CREATE DATABASE LINK sales CONNECT TO CURRENT USER USING 'sales'; 
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Note: To use a current user database link, the current user must 
be a global user on both databases involved in the link. 

See Also: Oracle Database SQL Language Reference for more syntax 
information about creating database links 

Using Connection Qualifiers to Specify Service Names Within Linl( Names 

In some situations, you may want to have several database links of the same type (for 
example, public) that point to the same remote database, yet establish connections to 
the remote database using different communication pathways. Some cases in which 
this strategy is useful are: 

■ A remote database is part of an Oracle Real Application Clusters configuration, so 
you define several public database links at your local node so that coruiections can 
be estabhshed to specific instances of the remote database. 

■ Some clients connect to the Oracle Database server using TCP/IP while others use 
DECNET 

To facilitate such functionality, the database lets you create a database link with an 
optional service name in the database link name. When creating a database link, a 
service name is specified as the trailing portion of the database link name, separated 
by an @ sign, as in ©sales. This string is called a connection qualifier. 

For example, assume that remote database hq . acme . com is managed in a Oracle 
Real Application Clusters environment. The hq database has two instances named 
hq_l and hq_2. The local database can contain the following public database links to 
define pathways to the remote instances of the hq database: 

CPEATE PUBLIC DATABASE LINK hq.acine.com@hq_l 

USING '3tring_to_hq_l' ; 
CPEATE PUBLIC DATABASE LINK hq.acme.com@hq_2 

USING '3tring_to_hq_2' ; 
CREATE PUBLIC DATABASE LINK hq.acme.com 

USIHG ' string_to_hq ' r 

Notice in the first two examples that a service name is simplv a part of the database 
link name. The text of the service name does not necessarily indicate how a connection 
is to be established; this information is specified in the service name of the USING 
clause. Also notice that in the third example, a service name is not specified as part of 
the link name. In this case, just as when a service name is specified as part of the link 
name, the instance is determined by the USING string. 

To use a service name to specify a particular instance, include the service name at the 
end of the global object name: 

SELECT ' FROM scott ,erap@hq.acrae,com@hq_l 

Note that in this example, there are two @ symbols. 



Using Shared Database Links 



Every application that references a remote server using a standard database link 
establishes a connection between the local database and the remote database. Many 
users running applications simultaneously can cause a high number of connections 
between the local and remote databases. 
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Shared database links enable vou to limit the number of network connections required 
between the local server iind the remote server. 

This section contains the following topics: 

■ Determining Whether to Use Shared Database Links 

■ Creating Shared Database Links 

■ Configuring Shared Database Links 

See Also: "What Are Shared Database Links?" on page 29-7 for a 
conceptual overview of shared database links 

Determining Whether to Use Shared Database Links 

Look carefullv at vour application and shared server configuration to determine 
whether to use shared links, A simple guideline is to use shared database links when 
the number of users accessing a database link is expected to be much larger than the 
number of server processes in the local database. 

The following table illustrates three possible configurations involving database links: 



Link Type 



Server Mode 



Consequences 



Nonshdred Dedicated /shared If your application uses a star\da.rd public database 

server link, and 100 users simultaneously require a 

connection, then 100 direct network connections to 
the renjote database are required. 



Shared Shared server If 10 shared server processes exist in the local 

shared server mode database, then 100 users that 
use the same database link require 10 or fewer 
I network connections to the remote server. Each 

local shared server process may only need one 
connection to the remote server 



Shared 



Dedicated If 10 clients connect to a local dedicated server, and 

each client has 10 sessions on the same connection 
(thus establishing 100 sessions overall), and each 
session references the same remote database, then 
onlv 10 connections are needed. With a nonshared 
database link, 100 connections are needed. 



Shared database links are not useful in all situations. Assume that onlv one user 
accesses the remote server. If this user defines a shared database link and 10 shared 
server processes exist in the local database, then this user can require up to 10 netivork 
connections to the remote server. Because the user can use each shared server process, 
each process can estabhsh a connection to the remote server. 

Clearly, a nonshared database link is preferable in this situation because it requires 
onlv one network connection. Shared database links lead to more network connections 
in single-user scenarios, so use shared links only when many users need to use the 
same link. Tvpicallv, shared links are used for public database links, but can also be 
used for private database links when many chents access the same local schema {and 
therefore the same private database link). 
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Note: In a multitiered environment, there is a restriction that if 
you use a shared database link to connect to a remote database, 
then that remote database cannot Unl; to another database with a 
database link that cannot be migrated. That link must use a shared 
server, or it must be another shared database hnk. 



Creating Shared Database Links 



To create a shared database link, use the keyword SHARED in the CREATE DATABASE 
LINK statement: 

CREATE SHARED DATABASE LINK dblink_naine 

[CONMECT TO usemame IDENTIFIED BY password] | [CONHECT TO CURRENT_USER] 
AUTHENTICATED BY scheind_niune IDENTIFIED BY password 
[DSIHG ' service_naine' ] ; 

Whenever you use the keyword SHARED, the clause AUTHENTICATED BY is required. 
The schema specified in the AUTHENTICATED BY clause must exist in the remote 
database and must be granted at least the CREATE SESSION privilege. The credentials 
of this schema can he considered the authentication method between the local 
database and the remote database. These credentials are required to protect the remote 
shared server processes from clients that masquerade as a database link user and 
attempt to gain unauthorized access to information. 

After a connection is made with a shared database link, operations on the remote 
database proceed with the privileges of the CONNECT TO user or CURRENT_USER, not 
the AUTHENTICATED BY schema. 

The following example creates a fixed user, shared link to database sales, connecting 
as scott and authenticated as linkuser: 

CREATE SHARED DATABASE LINK link2EaleE 
COHHECT TO scott IDENTIFIED BY tiger 
AUTHENTICATED BY lintuser IDENTIFIED BY ostrich 
USING 'sales' ; 

See Also: Ornclc Database SQL Language Reference for information 

about the CREATE DATABASE LINK statement 

Configuring Shared Database Linl<s 

You can configure shared database links in the following ways: 

■ Creating Shared Links to Dedicated Ser\'ers 

■ Creating Shared Links to Shared Servers 

Creating Shared Links to Dedicated Servers 

In the configuration illustrated in Figure 30-1, a shared server process in the local 
server owns a dedicated remote server process. The advantage is that a direct network 
transport exists beh,veen the local shared server and the remote dedicated server A 
disadvantage is that extra back-end server processes are needed. 
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Note: The remote server can either be a shared server or 
dedicated ser\'eT. There is a dedicated connection between the local 
and remote servers. When the remote ser\'er is a shared server, you 
can force a dedicated server connection bv using the 
(SERVER=DEDICATED) clause in the definition of the service name. 

Figure 30-1 A Shared Database Link to Dedicated Server Processes 
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Creating Shared Links to Shared Servers 

The configuration illustrated in Figure 30—2 uses shared server processes on the 
remote server. This configuration eliminates the need for more dedicated servers, but 
reqiLires the connection to go through the dispatcher on the remote server. Note that 
both the local and the remote server miLst be configured as shared servers. 
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Figure 30-2 Shared Database Link to Shared Server 
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See Also: Ornclc Daiabase Nel Services Adminisirator's Guide for 
information ahoLit the shared server option 



Managing Database Links 



Tliis section contains the following topics: 

■ Closing Database Links 

■ Dropping Database Links 

■ Limiting the Number of Active Database Link Connections 



Closing Database Links 



If vou access a database link in a session, then the link remains open until you close 
the session. A link is open in the sense that a process is active on each of the remote 
databases accessed through the link. This situation has the following consequences: 

■ If 20 users open sessions and access the same public link in a local database, then 
20 database link connections are open. 

■ If 20 users open sessions and each user accesses a private link, then 20 database 
hnk connections are open. 
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■ If one user starts a session and accesses 20 different links, then 20 database link 
connections are open. 

After you close a session, the links that were active in the session are automatically 
closed. You may have occasion to close the link manually. For example, close links 
when: 

■ The network connection established by a link is used infrequently in an 
application. 

■ The user session must be terminated. 

If vou want to close a link, issue the following statement, where linknaiiie refers to the 
name of the link: 

ALTER SES3I0H CLOSE DATABASE LIHK linknaiae: 

Note that this statement only closes the links that are active in vour current session. 



Dropping Database Links 



You can drop a database link just as vou can drop a table or view. If the link is private, 
then it must be in your schema. If the link is public, then you must have the DROP 

PUBLIC DATABASE LINK system privilege. 

The statement syntax is as foUows, where dblink is the name of the link: 

DROP [PUBLIC] DATABASE LINK dblink: 

Procedure for Dropping a Private Database Link 

1. Connect to the local database using SQL'Plus. For example, enter: 

COHHECT scott@IocaI_db 

2. Quer}' USER_DB_LINKS to view the links that vou own. For example, enter: 

SELECT DB_LIHK EHOM USER_DB_LINKS ; 
DB LINK 



SALES . US . ORACLE . COM 
MKTG.US.0RACLE.COM 
2 rows selected. 

3. Drop the desired link using the DROP DATABASE LINK statement. For example, 
enter: 

DROP DATABASE LIHK sales , us , oracle. com; 

Procedure for Dropping a Pubiic Database Link 

1. Connect to the local database as a user with the DROP PUBLIC DATABASE LIHK 
privilege. For example, enter: 

COHNECT SYSTEM@locaJ_db AS SYSDBA 

2. Quer}' DBA_DB_LINKS to view the public links. For example, enter: 

SELECT DB_LIIIK FROM USER_DB_LINKS 
WHERE OWNER = 'PUBLIC; 

DB LINK 
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DBL1.US.0HACIE.COM 
SALES.tIS.0RACLE.COM 
INST2.tJS.0RACLE.COM 
RMAH2 . tJS . ORACLE . COM 
4 rows selected. 

3. Drop the desired Jink using the DROP PtJBLIC DATABASE LINK statement. For 
example, enter: 

DROP PtJBLIC DATABASE LINK sales .us. oracle. com; 

Limiting the Number of Active Database Link Connections 

YoLL can limit the number of connections from a user process to remote databases 
using the static initialization parameter OPEW_LINKS. This parameter controls the 
number of remote connections that a single user session can use concurrently in 
distributed transactions. 

Note the following considerations for setting this parameter: 

■ The value should be greater than or equal to the number of databases referred to 
in a single SQL statement that references multiple databases. 

■ Increase the value if several distributed databases are accessed over time. Thus, if 
you regularly access three databases, set OPEN_LII\IKS to 3 or greater 

■ The default value for OPEH_LIHKS is 4. If OPEN_LIMKS is set to 0, then no 
distributed transactions are allowed. 

See Also: Oracle Database Reference for more information about 
the OPEN_LINKS initialization parameter 



Viewing Information About Database Links 

The data dictionary of each database stores the definitions of all the database links in 
the datiibase. You can use data dictionary tables and views to gain information tibout 
the links. This section contains the following topics: 

■ Determining Which Links Are in the Database 

■ Determining Which Link Connections Are Open 

Determining Which Links Are in the Database 

The following views show the database links that have been defined at the local 
database and stored in the data dictionary: 



View 


Purpose 


DBA_DB_LIHKS 


Lists all database links in the database. 


ALL_DB_LIHKS 


Lists all database links accessible to the connected user. 


USER_DB_LIHKS 


Lists all database links owned by the connected user. 



These data dictionary views contain the same basic information about database links, 
with some exceptions: 
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Column 


Which Views? 


Description 


OWHER 


1 All except USER_' 


The user who created the database link. If the link is 
public, then the user is listed as PUBLIC. 


DB_LIHK 


All 




The name of the database link. 


USERHAME 


All 




If the link definition includes a fixed user, then this 
column displays the username of the fixed user If 
there is no fixed user, the column is HULL. 


PASSWORD 


Only 


U3ER_* 


Not used. Maintained for backward compatibility 
only. 


HOST 


All 




The net service name used to connect to the remote 
database. 


CREATED 


All 




Creation time of the database link. 



Any user can query USER_DB_LINKS to determine which database links are available 
to that user Only those with additional privileges can use the ALL_DB_L INKS or 

DBA_DB_LINKS view. 

The following script queries the DBA_DB_LINKS view to access link information: 

COL OWNER FOEMAT alO 

COL USERNAME FORMAT A8 HEADING "USER" 

COL DB_LINK FORMAT A30 

COL HOST FORMAT A7 HEADING "SERVICE" 

SELECT ' FROM DBA_DB_LIIIKS 

/ 

Here, the script is invoked and the resulting output is shown; 
SQL>@link_Ecript 



OWMER 


DB_LIHK 


SYS 


TARGET.0S.ACME.COM 


PUBLIC 


DBL1.UK.ACME.COM 


PUBLIC 


RMAN2.US.ACME.COM 


PUBLIC 


DEPT.US.ACME.COM 


JANE 


DBL.UK.ACME.COM 


SCOTT 


EMP. US. ACME. COM 



USER 



SERVICE CREATED 



SYS 


instl 


23-JUH-99 


BLAKE 


ora51 


23-JUH-99 




inst2 


23-JUH-99 




inst2 


23-JUH-99 


BLAKE 


ora51 


23-JUH-99 


SCOTT 


inst2 


23-JON-99 



6 rows selected. 

Determining Which Link Connections Are Open 

You mav find it useful to determine which database link connections are currently 
open in vour session. Note that if you connect as SYSDBA, you cannot query a view to 
determine all the links open for all sessions; you can only access the link information 
in the session within which you are working. 

The following views show the database link connections that are currently open in 
your current session: 



View 



Purpose 



VS DELINK 



GVS DELINK 



Lists all open database links in your session, that is, all database 
links with the IH_TRAMSACTION column set to YES. 

Lists all open database links in your session along with their 
corresponding instances. This view is useful in an Oracle Real 
Application Clusters configuration. 
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These data dictionary views contain the same basic information about datiihase links, 
witli one exception: 



Column 


Which 
Views? 


Description 


DB_LINK 


All 


The name of the database link. 


OWNER_ID 


All 


The owner of the database link. 


LOGGED_OH 


All 


Wliether the database hnk is currently logged on. 


HETEROGENEOUS 


All 


Whether the database link is homogeneous (HO) or 
heterogeneous (YES). 


PROTOCOL 


All 


The communication protocol for the database link. 


OPEN_CURSOHS 


All 


Whether cursors are open for the database link. 


IN_TRfiNSACTIOH 


All 


Whether the database link is accessed in a 

transaction that has not yet been committed or 1 
rolled back. 


UPDATE_SENT 


All 


Whether there was an update on the database link. 


COMMIT_P0INT_STH 
ENGTH 


All 


The commit point strength of the transactions 
using the database link. 


INST_ID 


GVS DELINK 
□niy 


The instance from which the view^ information 
was obtained. 



For example, voii can create and execute the script below to determine which links are 
open (sample output included): 

COL DB_LI1K FORMAT A2 5 

COL OMNER_ID FORMAT 99999 HEADING "OWNID" 

COL L0GGED_OH FOEMAT A5 HEADING "LOGON" 

COL HETEROGENEOUS FORMAT A5 HEADING "HETER" 

COL PROTOCOL FORMAT A8 

COL OPEN_CURSORS FORMAT 999 HEADING "OPH_CHR" 

COL IN_TRA[JSACTIOH FORMAT A3 HEADING "TXN" 

COL UPDATE_SENT FORMAT A5 HEADING "UPDATE" 

COL C0MHIT_P0INT_3TREHGTH FORMAT 99999 HEADING "C.P.S" 

SELECT ' FROM VSDBLIHK 
/ 



SQL> edblink 
DB LINK 



OraiD LOGON HETER PROTOCOL OPN CUR TXN UPDATE C P S 



INST2.ACME.COM 



YES YES 



UNKN 



YES YES 



255 



Creating Location Transparency 



After vou have configured the necessarv database links, vou can use various tools to 
hide the distributed nature of the database system from users. In other words, users 
can access remote objects as if they were local objects. The following sections explain 
how to hide distributed functionality from users; 

■ Using Views to Create Location Transparency 

■ Using Synonyms to Create Location Transparency 
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■ Using Procedures to Create Location Transparency 

Using Views to Create Location Transparency 

Local views can provide location transparency for local and remote tables in a 
distributed database system. 

For example, assume that table emp is stored in a local database and table dept is 
stored in a remote database. To make these tables transparent to users of the system, 
you can create a view in the local database thatjoins local and remote data: 

CREATE VIE'/i company AS 

SELECT a.empno, a.sname, b.dname 

FROM scott.emp a, jward.dept@hq.acme.com b 

WHERE a.deptno = b.deptno; 

Figure 30-3 Views and Location Transparency 



SCOTT.EMP Table 



EMPNO 


ENAME 


JOB 


MGR 


HIREDATE 


SAL 


COMM 


DEPTNO 


7329 
7499 
7521 
7566 


SMITH 
ALLEN 
WARD 
JONES 


CLERK 
SALESMAN 
SALESMAN 
MANAGER 


7902 
7698 
7698 
7839 


1 7-DEC-ee 

20-FEB-89 
22-JUN-92 
02-APR-93 


800.00 
1600.00 
1250.00 
2975.00 


300.00 
300.00 
500.00 


20 
30 
30 
20 



COMPAh 

EMPNO 


YView 

ENAME 


DNAME 




7329 

7499 
7521 
7566 


SMITH 
ALLEN 
WARD 
JONES 


MARKETING 
SALES 
SALES 
MARKETING 





JWARD.DEPT 



DEPTNO 



20 
30 



DNAME 



MARKETING 

SALES 




When users access this view, thev do not need to know where the data is physically 
stored, or if data from more than one table is being accessed. Thus, it is easier for them 
to get required information. For example, the foilow^ing query provides data from both 
the local and remote database table: 

SELECT ' FROM company; 

The owner of the local view can grant onlv those object privileges on the local view 
that have been granted by the remote user. (The remote user is implied bv the tvpe of 
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database link). This is similar to privilege management for views that reference local 
data. 

Using Synonyms to Create Location Transparency 

Synonyms are useful in both distributed and non-distributed environments because 
they hide the identity of the underlying object, including its location in a distributed 
database svstem. If vou must rename or mo\'e the underlying object, you only need to 
redefine the synonym; applications based on the synonym continue to function 
normally. Svnonvms also simplify SQL statements for users in a distributed database 
svstem. 

Creating Synonyms 

You can create synonyms for the following: 

Tables 

Tvpes 

Views 

Materialized views 

Sequences 

Procedures 

Functions 

Packages 

All synonyms are schema objects that are stored in the data dictionary of the database 
in which they are created. To simplify remote table access through database links, a 
synonym can allow single-word access to remote data, hiding the specific object name 
and the location from users of the synonym. 

The syntax to create a svnonym is: 

CliEATE [PUBLIC] syiionym_name 

FOR [schema. ] object_namelSdatabase_link._na!ne] ; 

where: 

■ PUBLIC is a keyword specifying that this synonvm is available to all users. 
Omitting this parameter makes a synonym private, and usable only by the creator. 
Public synonyms can be created only by a user with CREATE PUBLIC SYNONYM 
system privilege. 

■ synonym_naine specifies the alternate object name to be referenced by users and 
applications. 

■ schema specifies the schema of the object specified in object_name. Omitting 
this parameter uses the schema of the creator as the schema of the object, 

■ object_name specifies either a table, view, sequence, materialized view, t>'pe, 
procedure, function or package as appropriate. 

■ database_link_name specifies the database link identifying the remote 
database and schema in which the object specified in object_name is located, 

A synonym must be a uniquely named object for its schema. If a schema contains a 
schema object and a public synonym exists with the same name, then the database 
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alwavs finds the schema object when the user that owns the schema references that 
name. 

Example: Creating a Public Synonym 

Assume that in ever\' database in a distributed database svstem, a pubUc synonym is 
defined for the scot t . emp table stored in the hq database: 

CREATE PUBLIC SYHOHYM emp FOK ECott.einp@hq.acine.com; 

You can design an employee management application without regard to where the 
application is used because the location of the table scott . empOhg. acme . com is 
hidden by the public synonyms, SQL statements in the application access the table by 
referencing the public synonym emp. 

Furthermore, if vou moye the emp table from the hq database to the hr database, then 
you only need to change the public synon\'ms on the nodes of the system. The 
employee management application continues to function properly on all nodes. 

Managing Privileges and Synonyms 

A synonym is a reference to an actual object, A user who has access to a synonym for a 
particular schema object must also haye privileges on the underlying schema object 
itself. For example, if the user attempts to access a synonym but does not have 
privileges on the table it identifies, an error occurs indicating that the table or yievi' 
does not exist. 

Assume scott creates local synonym emp as an alias for remote object 
scott . emp@ sales . acme .com. scott cannot grant object privileges on the 
synonym to another local user, scott cannot grant local privileges for the synonym 
because this operation amounts to granting priyileges for the remote emp table on the 
sales database, which is not allowed. This behavior is different from priyilege 
management for synonyms that are aliases for local tables or views. 

Therefore, you cannot manage local privileges when synonyms are used for location 
transparency. Security for the base object is controlled entirely at the remote node. For 
example, user admin cannot grant object privileges for the emp_sYn synonym. 

Unlike a database link referenced in a view or procedure definition, a database hnk 
referenced in a synonym is resolved by first looking for a private link owned by the 
schema in effect at the time the reference to the synonym is parsed. Therefore, to 
ensure the desired object resolution, it is especially important to specify the schema of 
the underlying object in the definition of a synonym. 

Using Procedures to Create Location Transparency 

PL /SQL program units called procedures can provide location transparency. You 
have these options: 

■ Using Local Procedures to Reference Rem.ote Data 

■ Using Local Procedures to Call Remote Procedures 

■ Using Local Synonyms to Reference Remote Procedures 

Using Local Procedures to Reference Remote Data 

Procedures or functions (either standalone or in packages) can contain SQL statements 
that reference remote data. For example, consider the procedure created by the 
follovi'ing statement: 

CREATE PROCEDURE fi!:e_emp (enuin NTMBER) AS 

Managing a Distributed Database 30-21 



Crealing Localion Transparency 



BEGIH 

DELETE FROM emp@hq.acme.com 

WHERE empno = enum; 
END; 

When a user or application calls the f ire_emp procedure, it is not apparent that a 
remote table is being modified. 

A second layer of location transparency is possible when the statements in a procedure 
indirectly reference remote data using local procedures, views, or synonyms. For 
example, the following statement defines a local synonym: 

CliEATE SYMONYM emp FOR emp@hq.acme.com; 

Given this synonym, you can create the f ire_emp procedure using the following 
statement: 

CHEATE PROCEDURE fire_emp (enum MMBER) AS 
BEGIH 

DELETE FROM emp IvTIERE empno = enum; 
END; 

If vou rename or move the table empShq, then you only need to naodify the local 
svnonym that references the table. None of the procedures and applications that call 
the procedure require modification. 

Using Local Procedures to Call Remote Procedures 

You can use a local procedure to call a remote procedure. The remote procedure can 
then execute the required DML. For example, assume that scott connects to 
local_db and creates the following procedure: 

COHMECT scott@local_db 

CliEATE PROCEDURE fire_emp (enum tTOMBER) 

AS 

BEGIH 

EXECUTE tenn_empehq. acme. com; 
END; 

Now, assume that scott connects to the remote database and creates the remote 
procedure: 

COHMECT scott@hq.acme.com 

CREATE PROCEDURE teniL_emp (enum HUMBER) 

AS 

BEGIH 

DELETE FROM emp I'fflERE empno = enum; 
END; 

When a user or application connected to local_d.b calls the f ire_emp procedure, 
this procedure in turn calls the remote term_emp procedure on hq . acme . com.. 

Using Local Synonyms to Reference Remote Procedures 

For example, scott connects to the local sales . acme . com database and creates the 
following procedure: 

CREATE PROCEDURE fire_emp (enum NUMBER) AS 

BEGIH 

DELETE FROM emp@hq.acrae.com 
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WHERE empno = enum; 
END; 

User peggy then connects to the supply, acme . com database and creates the 
following synonym for the proceduie that scott created on the remote sales 
database: 

SQL> COMECT peggy@supply 

SQL> CREftTE PUBLIC SYHOIJYM emp FOR scott.fire_emp@sales.acme.com; 

A local user on supply can use this synonvm to execute the procedure on sales. 

Managing Procedures and Privileges 

Assume a local procedure includes a statement that references a remote table or view. 
The owner of the local procedure can grant the execute privilege to any user, thereby 
giving that user the ability to execute the procedure and, indirectly, access remote 
data. 

In general, procedures aid in security. Privileges for objects referenced within a 
procedure do not need to be explicitly granted to the calling users. 



Managing Statement Transparency 



The database allows the following standard DML statements to reference remote 
ables: 

SELECT (queries) 

INSERT 
UPDATE 
DELETE 

SELECT . . . FOR UPDATE (not always supported in Heterogeneous Systems) 

LOCK TABLE 

Queries including joins, aggregates, subqueries, and SELECT . . . FOR UPDATE can 
reference any number of local and remote tables and views. For example, the 
following query joins information from two remote tables: 

SELECT e.empno, e.enarne, d.dnaine 

FROM scott.emp@3ales.division3.acme.com e, jward.dept@hq.acme.com d 
WHERE e.deptno = d.deptno; 

In a homogeneous environment, UPDATE, INSERT, DELETE, and LOCK TABLE 
statements can reference both local and remote tables. No programming is necessary 
to update remote data. For example, the following statement inserts new rows into the 
remote table emp in the scott. sales schema by selecting rows from the emp table in 
the jward schema in the local database: 

IM3ERT IHTO scott.emp@sales.division3.acme.com 
SELECT ' FROM jward. emp; 

Restrictions for Statement Transparency: 

Several restrictions apply to statement transparency. 

■ Data manipulation language statements that update objects on a remote 

non-Oracle Database system cannot reference any objects on the local Oracle 
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Database. For example, a statement such as the following will cause an error to be 
raised: 

INSERT IHTO reraote_table@link as SELECT • FROM local_talile; 

Within a single SQL statement, all referenced LONG and LONG RAW columns, 
sequences, updated tables, and locked tables must be located at the same node. 

The database does not allow remote DDL statements (for example, CREATE, 
ALTER, and DROP) in homogeneous systems except through remote execution of 
procedures of the DBMS_SQL package, as in this example: 

DBMS_SQL.PAR3E@link_name(crs, 'drop table emp ' , v7) ; 

Note that in Heterogeneous Systems, a pass-through facility lets you execute DDL. 

The LIST CHAINED ROWS clause of an ANALYZE statement cannot reference 
remote tables. 

In a distributed database system, the database alwavs evaluates 
environment ally -de pendent SQL functions such as SYSDATE, USER, UID, and 
USERENV with respect to the local server, no matter where the statement (or 
portion of a statement) executes. 



Note: Oracle Database supports the USERENV function for queries 
only. 

■ A number of performance restrictions relate to access of remote objects: 

- Remote views do not have statistical data. 

- Queries on partitioned tables may not be optimized. 

- No more than 20 indexes are considered for a remote table. 

- No more than 20 columns are used for a composite index. 

■ There is a restriction in the Oracle Database implementation of distributed read 
consistency that can cause one node to be in the past with respect to another node. 
In accordance with read consistency, a querv may end up retrieving consistent, 
but out-of-date data. See "Managing Read Consistency " on page 33-19 to learn 
how to manage this problem. 

See Also: Oracle Database PL/SQL Packages and Types Reference for 
more information about the DBMS_SQL package 

Managing a Distributed Database: Examples 

This section presents examples illustrating management of database links: 
Example 1: Creating a Public Fb<ed User Database Link 
Example 2: Creating a Public Fixed User Shared Database Link 
Example 3: Creating a Public Connected User Database Link 
Example 4: Creating a Public Connected User Shared Database Link 
Example 5; Creating a Pubhc Current User Database Link 
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Example 1: Creating a Public Fixed User Database Link 

The following statements connect to the local database as jane and create a public 
fixed user database link to database sales for scott. The database is accessed 
through its net service name sldb: 

COHNECT janeSlocal 

CREATE PUBLIC DATABASE LINK sales.division3.acme.com 
COHNECT TO scott IDENTIFIED BY tiger 
USING 'sldb'; 

After executing these statements, any user connected to the local database can use the 
sales . divisions . acme . com database link to connect to the remote database. Each 
user connects to the schema scott in the remote database. 

To access the table emp table in scott's remote schema, a user can issue the following 
SQL query: 

SELECT ' FROM einp@Eales.division3.aome.com; 

Note that each application or user session creates a separate connection to the common 
account on the server. The connection to the remote database remains open for the 
duration of the application or user session. 

Example 2: Creating a Public Fixed User Shared Database Link 

The following example connects to the local database as dana and creates a public link 
to the sales database (using its net service name sldb). The link allows a cormection 
to the remote database as scott and authenticates this user as scott: 

COHNECT danaSlocal 

CREATE SHARED PUBLIC DATABASE LINK sales.division3.acme.com 
COHHECT TO scott IDENTIFIED BY tiger 
AUTHENTICATED BY scott IDENTIFIED BY tiger 
USIHG 'sldb'; 

Now, any user connected to the local shared server can use this database link to 
connect to the remote sales database through a shared server process. The user can 
then query tables in the scott schema. 

In the preceding example, each local shared server can establish one connection to the 
remote server. Whene\'er a local shared server process needs to access the remote 
server through the sales . divisions .acme .com database link, the local shared 
server process reuses established network connections. 

Example 3: Creating a Public Connected User Database Link 

The following example connects to the local database as larry and creates a public 
hnk to the database with the net service name sldb: 

COHNECT larrySlooal 

CREATE PUBLIC DATABASE LINK redwood 
USING 'sldb'; 

Any user connected to the local database can use the redwood database link. The 
connected user in the local database w^ho uses the database link determines the remote 
schema. 
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If Ecott is the connected user and uses the database hnk, then the database hnk 
connects to the remote schema scott. If f ox is the connected user and uses the 
database link, then the database link connects to remote schema f ox. 

The following statement fails for local user fox in the local database when the remote 
schema fox cannot resolve the emp schema object That is, if the fox schema in the 
sales .divisions . acme . com does not have emp as a table, view, or (public) 
svnonym, an error will be returned. 

CONNECT foxSlocal 

SELECT ' FROM empSredwood; 

Example 4; Creating a Public Connected User Shared Database Link 

The following example connects to the local database as neil and creates a shared, 
public link to the sales database (using its net sen'ice name sldb). The user is 
authenticated bv the userid /password of crazy/horse. The following statement 
creates a public, connected user, shared database link: 

COHMECT neilSlocal 

CREATE SHARED PUBLIC DATABASE LINK sales.division3.acme.com 
AUTHENTICATED BY crazy IDENTIFIED BY horse 
USING 'sldb'; 

Each user connected to the local server can use this shared database link to connect to 
the remote database and query the tables in the corresponding remote schema. 

Each local, shared server process establishes one connection to the remote server 
Whenever a local server process needs to access the remote server through the 
sales .divisions . acme . com database link, the local process reuses established 
network connections, even if the connected user is a different user 

If this database link is used frequentlv, eventuallv e\'ery shared server in the local 
database will have a remote connection. At this point, no more physical connections 
are needed to the remote server, even if new users use this shared database link. 

Example 5: Creating a Public Current User Database Link 

The following example connects to the local database as the connected user and 
creates a public link to the sales database (using its net service name sldb). The 
following statement creates a public current user database link: 

COHMECT bartSlocal 

CREATE PUBLIC DATABASE LINK saleE.division3.acme.com 
CONNECT TO CUERENT_USER 
USING 'sldb'; 



Note: To use this link, the current user must be a global user. 



The consequences of this database link are as follows: 

Assume scott creates local procedure f ire_emp that deletes a row from the remote 
emp table, and grants execute privilege on f ire_emp to ford, 

COHMECT scottelocal db 
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CREATE PROCEDURE fire_emp (enuin NUMBER) 

AS 

EEGIH 

DELETE FROM emp@sales.diviEion3.acme.com 

WHERE erapno=enum; 
END; 

GRANT EXECUTE OH fire_emp TO ford; 

Now, assume that ford connects to the local database and runs scott's procedure: 
CONNECT ford@local_db 

EXECUTE PROCEDURE scott . f ire_emp (enuin 10345); 

When ford executes the procedure scott . f ire_emp, the procedure runs under 
scott's privileges. Because a current user database link is used, the connection is 
established to scott's remote schema, not ford's remote schema. Note that scott 
must be a global user while ford does not have to be a global user. 

Note: If a connected user database link were used instead, the 
connection would be to ford's remote schema. For more 
information about invoker rights and privileges, see the Oracle 
Database PL/SQL Language Reference. 



You can accomplish the same result bv using a fixed user database link to scott's 
remote schema. 
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Developing Applications for a Distributed 

Database System 



In this chapter: 

Managing the Distribution of Application Data 
Controlling Connections Established bv Database Links 
Maintaining Referential Integrity' in a Distributed System 
Tuning Distributed Queries 
Handling Errors in Remote Procedures 

See Also: Oiack Database Advanced Application Developer's Guide 
for more information about application development in an Oracle 
Database environment 



Managing the Distribution of Application Data 



In a distributed database environment, coordinate with the database administrator to 
determine the best location for the data. Some issues to consider are: 

Number of transactions posted from each location 

Amount of data {portion of table) used by each node 

Performance characteristics and reliability' of the network 

Speed of various nodes, capacities of disks 

Importance of a node or link when it is unavailable 

Need for referential integritv among tables 



Controlling Connections Established by Database Linits 



When a global object name is referenced in a SQL statement or remote procedure call, 
database links establish a connection to a session in the remote database on behalf of 
the local user. The remote connection and session are only created if the connection 
has not already been established previously for the local user session. 

The connections and sessions established to remote databases persist for the duration 
of the local user's session, unless the application or user explicitiv terminates them. 
Note that when you issue a SELECT statement across a database link, a transaction 
lock is placed on the undo segments. To rerelease the segment, you must issue a 
COMMIT or ROLLBACK statement. 
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Terminating remote connections establislied using database links is useful for 
di SCO ruiec ting high cost connections that are no longer required by the application. 
You can terminate a remote connection and session using the ALTER SESSION 
statement with the CLOSE DATABASE LINK clause. For example, assume you issue 
the following transactions: 

SELECT ' FROM empSEales; 
COMMIT; 

The following statement terminates the session in the remote database pointed to by 
the sales database link: 

ALTER SESSION CLOSE DATABASE LIHK sales; 

To close a database link connection in your user session, you must have the ALTER 
SESSION system privilege. 

Note: Before closing a database link, first close all cursors that use 
the link and then end your current transaction if it uses the link. 

See Also: Oracle Database SQL Language Reference for more 
information about the ALTER SESSION statement 

Maintaining Referential Integrity in a Distributed System 

If a part of a distributed statement fails, for example, due to an integrit}' constraint 
violation, the database returns error number ORA-02055. Subsequent statements or 
procedure calls return error number ORA-02067 until a ROLLBACK or ROLLBACK TO 
SAVEPOINT is issued. 

Design vour application to check for any returned error messages that indicate that a 
portion of the distributed update has failed. If you detect a failure, you should roll 
back the entire transaction before allowing the application to proceed. 

The database does not permit declarative referential integritv constraints to be defined 
across nodes of a distributed svstem. In other words, a declarative referential integrity 
constraint on one table cannot specify a foreign key that references a primar}' or 
unique key of a remote table. Nevertheless, vou can maintain parent/child table 
relationships across nodes using triggers. 

If vou decide to define referential integrity across the nodes of a distributed database 
using triggers, be aware that network failures can limit the accessibility of not only the 
parent table, but also the child table. For example, assume that the child table is in the 
sales database and the parent table is in the hq database. If the network connection 
between the two databases fails, some DML statements against the child table (those 
that insert rows into the child table or update a foreign key value in the child table) 
cannot proceed because the referential integritv triggers must have access to the parent 
table in the hq database. 

See Also: Oracle Database PL/SQL Language Reference for more 
information about using triggers to enforce referential integrity 



Tuning Distributed Queries 



The local Oracle Database server breaks the distributed query into a corresponding 
number of remote queries, which it then sends to the remote nodes for execution. The 
remote nodes execute the queries and send the results back to the local node. The local 
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node then performs anv necessary post-processing and returns the results to the user 
or apphcation. 

You have several options for designing your application to optimize query processing. 
This section contains the following topics: 

■ Using Collocated Inline Views 

■ Using Cost-Based Optimization 

■ Using Hints 

■ Analyzing the Execution Plan 



Using Collocated Inline Views 



The most effective way of optimizing distributed queries is to access the remote 
databases as httle as possible and to retrieve only the required data. 

For example, assume vou reference five remote tables from two different remote 
databases in a distributed query and have a complex filter (for example, WHERE 
rl . salary -F r2 . salary > 50000). You can improve the performance of the query 
bv rewriting the querv to access the remote databases once and to apply the filter at 
the remote site. This rewrite causes less data to be transferred to the querv execution 
site. 

Rewriting your querv to access the remote database once is achieved by using 
collocated inline views. The following terms need to be defined: 

■ Collocated 

Two or more tables located in the same database. 

■ Inline view 

A SELECT statement that is substituted for a table in a parent SELECT statement. 
The embedded SELECT statement, shown within the parentheses is an example of 
an inline view: 

SELECT e.empno, e.ename, d.deptrio, d.dname 
FROM (SELECT empno, ename from 
Sorcl. world) e, dept d; 



■ Collocated inline vieiv 

An inline view that selects data from multiple tables from a single database onlv. 
It reduces the amount of times that the remote database is accessed, improving the 
performance of a distributed querv. 

Oracle recommends that vou form vour distributed querv using coUocated inline 
views to increase the performance of your distributed quer\'. Oracle Database 
cost-based optimization can transparentlv rewrite manv of vour distributed queries to 
take advantage of the performance gains offered by collocated inline views. 



Using Cost-Based Optimization 



In addition to rewriting your queries with collocated inline views, the cost-based 
optimization method optimizes distributed queries according to the gathered statistics 
of the referenced tables and the computations performed bv the optimizer 

For example, cost-based optimization analyzes the following querv. The example 
assumes that table statistics are available. Note that it analyzes the query inside a 

CREATE TABLE statement: 
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CREATE TaBLE AS 



SELECT l.a, l.b, rl.c, rl.d, rl.e, r2 .b, r2.c 
FROM local 1, rsmotel rl, remots2 r2 

WHERE l.c = r.c 

AND rl.c = r2.c 

AND r.e > 300 



and rewrites it as: 

CREATE TABLE AS I 



SELECT l.a, l.b, v.c, v.d, v.e 
FROM ( 

SELECT rl.c, rl.d, rl.e. r2 .b, r2.c 
FROM remotel rl, remote2 r2 
WHERE rl.c = r2 .c 
AND rl.e > 300 
] V, local 1 
WHERE l.c = rl.c 



The alias v is assigned to the inline view, which can then be referenced as a table in the 
preceding SELECT statement. Creating a collocated inline view reduces the amount of 
queries performed at a remote site, thereby reducing costly network traffic. 

How Does Cost-Based Optimization Work? 

The main task of optimization is to rewrite a distributed quer}' to use collocated inline 
views. This optimization is performed in three steps: 

1. All mergeable views are merged. 

2. Optimizer performs collocated query block test. 

3. Optimizer rewrites query using collocated irdine view^s. 

After the query is rewritten, it is executed and the data set is returned to the user. 

While cost-based optimization is performed transparently to the user, it is unable to 
improve the performance of several distributed querv scenarios. Specifically, if vour 
distributed query contains anv of the following, cost-based optimization is not 
effective: 

■ Aggregates 

■ Sub queries 

■ Complex SQL 

If vour distributed querv contains one of these elements, see "Using Hints" on 
page 31-6 to learn how you can modify your querj' and use hints to improve the 
performance of vour distributed query. 

Setting Up Cost-Based Optimization 

After you have set up your svstem to use cost-based optin\ization to improve the 
performance of distributed queries, the operation is transparent to the user In other 
words, the optimization occurs automaticallv when the quer\" is issued. 

You need to complete the following tasks to set up vour systen\ to take advantage of 
cost-based optimization: 

■ Setting Up the Environment 
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■ Analyzing Tables 

Setting Up the Environment To enable cost-based optimization, setthe 0PTIMIZER_M0DE 
initialization parameter to CHOOSE or COST. You can set this parameter by: 

■ Modifying the OPTIMIZER_MODE parameter in the initialization parameter file 

■ Setting it at session level by issuing an ALTER SESSION statement 

Issue one of the following statements to set the OPTIMIZER_MODE initialization 
parameter at the session ievel: 

ALTER SESSIOH OPTfflIZER_MODE = CHOOSE; 
ALTER EESSIOM OPTfflIZER_MODE = COST; 

See Also: Oracle Database Performance Tuning Guide for 
information on setting the OPTIMIZER_MODE initialization 
parameter in the parameter file and for configuring your svstem to 
use a cost-based optimization method 

Analyzing Tables For cost-based optimization to select the most efficient path for a 
distributed query, you must provide accurate statistics for the tables involved. You do 
this using the DBMS_STATS package or the ANALYZE statement. 

Note: You must connect locally with respect to the tables when 
executing the DBMS_STATS procedure or ANALYZE statement. For 
example, vou cannot execute the following; 

AMALYZE TABLE r emoteSr emote . com COMPUTE STATISTICS; 

You must first connect to the remote site and then execute the 
preceding ANALYZE statement, or the equivalent DBMS_STATS 
procedure. 

The following DBMS_3TAT3 procedures enable the gathering of certain classes of 
optimizer statistics: 

■ GATHER_INDEX_STATS 

■ GATHER_TABLE_STATS 

■ GATHER_SCHEMA_STATg 

■ GATHER_DATABASE_STAT3 

For example, assume that distributed transactions routinelv access the scott . dept 
table. To ensure that the cost-based optimizer is still picking the best plan, execute the 
following: 

BEGIH 

DBMS_STATS . GATHER_TABLE_STATS ( ' scott ' , ' dept ' ] ; 
EHD; 

See Also: 

■ Oracle Database Performance Tuning Guide for information about 
generating statistics 

■ Orach Database PL/SQL Packages and Types Reference for 
additional information on using the DBM3_STATS package 
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Using Hints 



If a statement is not stifficiently optimized, then you can use tiints to extend the 
capabilit}' of cost-based optimization. Specifically, if you write vour own querv to 
utilize collocated inline views, instriLct the cost-based optimizer not to rewrite your 
distributed query. 

Additionally, if you have special knowledge about the database envirorunent (such as 
statistics, load, network and CPU limitations, distributed queries, and so forth), you. 
can specify a hint to guide cost-based optimization. For example, if you have written 
your own optimized querv using collocated inline views that are based on your 
knowledge of the database environment, specify the NO_MERGE hint to prevent the 
optimizer from rewriting vour query. 

This technique is especially helpful if your distributed query contains an aggregate, 
subquerv, or complex SQL. Because this tvpe of distributed querv cannot be rewritten 
bv the optimizer, specifying NO_MERGE causes the optimizer to skip the steps 
described in "How Does Cost-Based Optimization Work?" on page 31^. 

The DRIVING_SITE hint lets vou define a remote site to act as the query execution 
site. In this way, the query executes on the remote site, which then returns the data to 
the local site. This hint is especially helpful when the remote site contains the majority 
of the data. 

See Also: Oracle Database Pcrfomiance Tuning Guide for more 
information about using hints 

Using the NO_MERGE Hint 

The NO_MERGE hint prevents the database from merging an inline view into a 
potentially non-collocated SQL statement (see "Using Hints" on page 31-6). This hint is 
embedded in the SELECT statement and can appear either at the beginning of the 
SELECT statement with the inline view as an argument or in the querv block that 
defines the inline view. 

/*■ with argument */ 

SELECT /*+HO_MERGE(v}'/ tl.x, v.avgj 

FROM tl, (SELECT x, AVG(y) AS avg_y FROM t2 GROUP BY x) v, 
WHERE tl.x = v.x AND tl.y = 1; 

/*■ in query block '/ 

SELECT tl.x, v.avg_y 

FROM tl, (SELECT /•+NO_HERGE*/ x, AVG(y) A5 avg_y FROM t2 GROUP BY x) v, 
WHERE tl.x = v.x AND tl.y = 1; 

Typically, you use this hint when you have developed an optimized query based on 
your knowledge of vour database environment. 

Using the DRIVING_SITE Hint 

The DRIVIISIG_SITE hint lets vou specify the site where the querv execution is 
performed. It is best to let cost-based optimization determine where the execution 
should be performed, but if you prefer to override the optimizer, you can specify the 
execution site manuallv. 

Following is an example of a SELECT statement with a DRI VI WG_S I TE hint: 

SELECT /*+DRIVING_3ITE(dept)'/ * FROM emp, dept@remote.com 

WHERE emp.deptno = dept.deptno; 
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Analyzing the Execution Plan 



An important aspect to tuning distributed queries is analyzing the execution plan. The 
feedback that you receive from your analysis is an important element to testing and 
verifying your database. Verification becomes especially important when you want to 
compare plans. For example, comparing the execution plan for a distributed query 
optimized by cost-based optimization to a plan for a query manuaUy optimized using 
hints, collocated inline views, and other techniques. 

See Also: Oracle Database Performance Tuning Guide for detailed 
information about execution plans, the EXPLAIN PLAN statement, 
and how to interpret the results 

Preparing the Database to Store the Plan 

Before you can view the execution plan for the distributed query, prepare the database 
to store the execution plan. You can perform this preparation by executing a script. 
Execute the foUowing script to prepare your database to store an execution plan: 

SQL> SUTLXPLM.SQL 



Note: The utlxplan . sql file can be found in the 

SORACLE_HOME/rdbnis/adinin directory. 



After you execute utlxplan. sql, a table, PLAN_TABLE, is created in the current 
schema to temporarily store the execution plan. 

Generating the Execution Plan 

After you have prepared the database to store the execution plan, you are ready to 
view the plan for a specified query. Instead of directly executing a SQL statement, 
append the statement to the EXPLAIN PLAN FOR clause. For example, you can 
execute the following: 

EXPLAIN PLAN FOR 
SELECT d.dnaine 
FROM dept d 

WHERE d.deptno 
IH (SELECT deptno 

FROM emp@orc2. world 
GROUP BY deptno 
HftVING COUHT (deptno) >3 
) 
/ 

Viewing the Execution Plan 

After you have executed the preceding SQL statement, the execution plan is stored 
temporarily in the PLAN_TABLE that you created earlier To view the results of the 
execution plan, execute the follovi'ing script: 

eUTLXPLS.SQL 



Note: The utlxpls .sql can be found in the 
$ORACLE_HOME/rdbms/adinin director)'. 
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Executing the utlxpls . sql script displays the execution plan for the SELECT 
statement that you specified. The results are formatted as follows: 

Plan Table 



Operation 



Haine 



Rows Bytes Cost 



Pstart Pstop 



SELECT STATEMENT | 

NESTED LOOPS j 

VIEW I 

REMOTE I 

TABLE ACCESS BY INDEX RoJdEPT 

INDEX UMIQUE SCAN PK_DEPT 



If vou are manually optimizing distributed queries by writing vour own collocated 
inline views or using hints, it is best to generate an execution plan before and after 
your manual optimization. With both execution plans, you can compare the 
effectiveness of your manual optimization and make changes as necessary to improve 
the performance of the distributed query. 

To view the SQL statement that will be executed at the remote site, execute the 
following select statement: 

SELECT OTHER 
FROM PLAM_TABLE 

WHERE operation = 'REMOTE'; 

Following is sample output: 

SELECT DISTINCT "Al" . "DEPTNO" FROM "EHP" "Al" 

GROUP BY "Al" ."DEPTHO" HAVING C0™T{ "Al" . "DEPTNO" ) >3 



Note: If you are having difficulty viewing the entire contents of 
the OTHER column, execute the following SQL'Plus command: 

SET LONG 9999999 



Handling Errors in Remote Procedures 



When the database executes a procedure locally or at a remote location, four tvpes of 
exceptions can occur: 

■ PL/SQL user-defined exceptions, which must be declared using the keyword 

EXCEPTION 

■ PL/SQL predefined exceptions such as the NO_DATA_F0UHD keyword 

■ SQL errors such asORA-00900 and OKA- 2 015 

■ Application exceptions generated using the RAISE_APPLICATIOH_ERROR() 
procedure 

When using local procedures, vou can trap these messages by writing an exception 
handler such as the following 

BEGIM 

EXCEPTION 

WHEN ZERO_DIVIDE THEN 

/* ... handle the exception */ 
END; 
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Notice that the WHEW clause requires an exception name. If the exception does not have 
a name, for example, exceptions generated with RAISE_APPLICATION_ERR0R, you 
can assign one using PRAGMA_EXCEPTIOW_IWIT. For example: 

DECLARE 

null_salary EXCEPTIOH; 

PRAGMft EXCEPTIOM_INIT{null_Ealary, -20101}; 
BEGIN 

RAISE_APPLICATIOH_ERROR(-20101, 'salary is missing'); 

EXCEPTIOH 

WHEN null_salary THEH 

END; 

When calling a remote procedure, exceptions can be handled by an exception handler 
in the local procedure. The remote procedure must return an error number to the local, 
calling procedure, which then handles the exception as shown in the previous 
example. Note that PL/SQL user-defined exceptions always return ORA- 6510 to the 
local procedure. 

Therefore, it is not possible to distinguish between two different user-defined 
exceptions based on the error number All other remote exceptions can be handled in 
the same manner as local exceptions. 

See Also: Oracle Database PL/SQL Language Reference for more 
information about PL /SQL procedures 
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In this chapter: 

What Are Distributed Tmnsactions? 

Session Trees for Distributed Transactions 

Two-Phase Commit Mechanism 

In-Doubt Transactions 

Distributed Transaction Processing: Case Study 



What Are Distributed Transactions? 



A distributed transaction inchides one or more statements that, individuaUy or as a 
group, update data on two or more distinct nodes of a distributed database. For 
example, assume the database configuration depicted in Figure 32-1: 



Figure 32-1 Distributed System 



emp table 




dept table 



bidg table 



SCOTT 



The following distributed transaction executed by scott updates the local sales 
database, the remote hq database, and the remote maint database: 

UPDATE scatt.dept@hq.UE.acme.com 
SET loc = 'REDWOOD SH0HE3 ' 
WHERE deptno = 10; 
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UPDATE scott.enp 

SET deptno = 11 

WHERE deptno = 10; 
UPDATE scott .bldgSmaint .us.acme.ctm 

SET room = 1225 

MHEHE room = 1163; 
COMMIT,- 



Note: If all statements of a transaction reference only a single 
remote node, then the transaction is remote, not distributed. 

There are two tvpes of permissible operations in distributed transactions: 

■ DML and DDL Transactions 

■ Transaction Control Statements 

DML and DDL Transactions 

The following are the DML and DDL operations supported in a distributed 
transaction: 

CREATE TABLE AS SELECT 
DELETE 

INSERT (default and direct load) 

LOCK TABLE 

SELECT 

SELECT FOR UPDATE 

You can execute DML and DDL statements in parallel, and INSERT direct load 
statements serially, but note the following restrictions: 

■ All remote operations must be SELECT statements. 

■ These statements must not be clauses in another distributed transaction. 

■ If the table referenced in the tablc_fxj.'rcsskiii_daiisi: of an INSERT, UPDATE, or 
DELETE statement is remote, then execution is serial rather than parallel. 

■ You cannot perform remote operations after issuing parallel DML/DDL or direct 
load INSERT. 

■ If the transaction begins using XA or OCI, it executes serially. 

■ No loopback operations can be performed on the transaction originating the 
parallel operation. For example, you cannot reference a remote object that is 
actually a synonym for a local object. 

■ If you perform a distributed operation other than a SELECT in the transaction, no 
DML is parallelized. 

Transaction Control Statements 

The following are the supported transaction control statements; 

■ COMMIT 

■ ROLLBACK 
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■ SAVEPOIWT 

See Also: Oracle Dalnbase SQL Language Reference for more 
ii\formation about these SQL statements 

Session Trees for Distributed Transactions 

As the statements in a distributed transaction are issued, the database defines a 
session tree of all nodes participating in the transaction. A session tree is a hierarchical 
model that describes the relationships among sessions and their roles. Figure 32—2 
illustrates a session tree: 



Figure 32-2 Example of a Session Tree 



mrSERT INTO orders . . . ; 

UPDATE inventory @ warehouse. . . ; 
UPDATE accts_rec 3 finance...; 

COMMIT; 



', SALES.ACME.COM 




WAREH0USE.ACME.COM 



RNANCE.ACME.COM 



^1 Global Coordinator 

^1 Commil Point Site 

^1 Database Server 

I I Client 



All nodes participating in the session tree of a distributed transaction assume one or 
more of the following roles: 



Role 



Database server 
Global coordinator 



Description 



Client A node that references information in a database belonging to a 

different node. 



A node that receives a request for information from, another node. 
The node that originates the distributed transaction. 



Local coordinator 



Commit point site 



A node that is forced to reference data on other nodes to complete 

its part of the transaction. 

The node that commits or rolls back the transaction as instructed 
by the global coordinator 



The role a node plavs in a distributed transaction is determined by: 

■ Whether the transaction is local or remote 

■ The commit point strength of the node ("Commit Point Site" on page 32-5) 
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Whether all requested data is available at a node, or whether other nodes need to 
be referenced to complete the transaction 



Whether the node is read-only 



Clients 



A node acts ns a client when it references information from a database on another 
node. The referenced node is a database server In Figure 32-2, the node sales is a 
chent of the nodes that host the warehouse and finance databases. 

Database Servers 

A database server is a node that hosts a database from which a client requests data. 

In Figure 32-2, an application at the sales node initiates a distributed transaction that 
accesses data from the warehouse and finance nodes. Therefore, 

sales . acme . com has the role of client node, and warehouse and finance are both 
database servers. In this example, sales is a database sen'er iind a client because the 
application also modifies data in the sales database. 

Local Coordinators 

A node that must reference data on other nodes to complete its part in the distributed 
transaction is called a local coordinator. In Figure 32—2, sales is a local coordinator 
because it coordinates the nodes it directly references: warehouse and finance . 
The node sales also happens to be the global coordinator because it coordinates all 
the nodes involved in the transaction. 

A local coordinator is responsible for coordinating the transaction among the nodes it 
communicates directlv with by: 

■ Receiving and relaying transaction status information to and from those nodes 

■ Passing queries to those nodes 

■ Receiving queries from those nodes and passing them on to other nodes 

■ Returning the results of queries to the nodes that initiated them 

Global Coordinator 

The node where the distributed transaction originates is called the global coordinator 
The database application issuing the distributed transaction is directly connected to 
the node acting as the global coordinator For example, in Figure 32-2. the transaction 
issued at the node sales references information from the database servers 
warehouse and finance. Therefore, sales . acme . com is the global coordinator of 
this distributed transaction. 

The global coordinator becomes the parent or root of the session tree. The global 
coordinator performs the following operations during a distributed transaction: 

■ Sends all of the distributed transaction SQL statements, remote procedure calls, 
and so forth to the directlv referenced nodes, thus forming the session tree 

■ Instructs all directly referenced nodes other than the commit point site to prepare 
the transaction 

■ Instructs the commit point site to initiate the global commit of the transaction if all 
nodes prepare successfully 
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Instructs all nodes to initiate a global rollback of the transaction if there is an abort 
response 



Commit Point Site 



The job of the commit point site is to initiate a commit or roll back operation as 
instructed by the global coordinator. The system administrator always designates one 
node to be the commit point site in the session tree by assigning all nodes a commit 
point strength. The node selected as commit point site should be the node that stores 
the most critical data. 

Figure 32-3 illustrates an example of distributed system, with sales sen'ing as the 
commit point site: 

Figure 32-3 Commit Point Site 



COMMIT POIHT STRENGTH = 75 




COMMIT POINT STRENGTH = lOD 



CaMMIT_POINT_STEENGTH = 50 

The commit point site is distinct from all other nodes involved in a distributed 
transaction in these wavs: 

■ The commit point site never enters the prepared state. Consequently, if the 
commit point site stores the most critical data, this data never remains in-doubt, 
even if a failure occurs. In failure situations, failed nodes remain in a prepared 
state, holding necessary locks on data until in-doubt transactions are resolved. 

■ The commit point site commits before the other nodes involved in the transaction. 
In effect, the outcome of a distributed transaction at the commit point site 
determines whether the transaction at all nodes is committed or rolled back: the 
other nodes follow the lead of the commit point site. The global coordinator 
ensures that all nodes complete the transaction in the same manner as the commit 
point site. 

How a Distributed Transaction Commits 

A distributed transaction is considered committed after all no n-comm it-point sites are 
prepared, and the transaction has been actuallv committed at the commit point site. 
The redo log at the commit point site is updated as soon as the distributed transaction 
is committed at this node. 

Because the commit point log contains a record of the commit, the transaction is 
considered committed even though some participating nodes may still be onlv in the 
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prepared state and the transaction not vet actually committed at these nodes. In the 
same wav, a distributed transaction is considered not committed if tiie commit has not 
been logged at the commit point site. 

Commit Point Strength 

Every database server must be assigned a commit point strength. If a database server 
is referenced in a distributed transaction, the value of its commit point strength 
determines which role it plays in the two-phase commit Specificallv, the commit point 
strength determines whether a given node is the commit point site in the distributed 
transaction and thus commits before all of the other nodes. This value is specified 
using the initialization parameter COMMIT_POINT_STRENGTH. This section explains 
how the database determines the commit point site. 

The commit point site, which is determined at the beginning of the prepare phase, is 
selected only from the nodes participating in the transaction. The following sequence 
of events occurs: 

1 . Of the nodes directly referenced by the global coordinator, the database selects the 
node with the highest commit point strength as the commit point site. 

2. The initially -selected node determines if anv of the nodes from which it has to 
obtain information for this transaction has a higher commit point strength. 

3. Either the node with the highest commit point strength directly referenced in the 
transaction or one of its servers with a higher commit point strength becomes the 
commit point site. 

4. After the final commit point site has been determined, the global coordinator 
sends prepare responses to ail nodes participating in the transaction. 

Figure 32^ shows in a sample session tree the commit point strengths of each node (in 
parentheses) and shows the node chosen as the commit point site: 



Figure 32-4 Commit Point Strengttis and Determination of the Commit Point Site 

SALES.ACME.COM 
(45) 




HQ.ACr/IE.COIW 
(165) 



WAREHOUSE.ACME.COnfl 
(140) 



FINANCE.ACME.COM 
{45) 



HFI.ACME.COM 
(«) 



^1 Global Coordinator 

^1 Cammit Point Site 

I I Database Server 

I I Client 



The following conditions apply when determining the commit point site: 
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■ A read-only node cannot be the commit point site. 

■ If multiple nodes directly referenced hv the global coordinator have the same 
commit point strength, then the database designates one of these as the commit 
point site. 

■ If a distributed transaction ends with a rollback, then the prepare and commit 
phases are not needed. Consequently, the database never determines a commit 
point site. Instead, the global coordinator sends a ROLLBACK statement to all 
nodes and ends the processing of the distributed transaction. 

As Figure 32—1 illustrates, the commit point site and the global coordinator can be 
different nodes of the session tree. The commit point strength of each node is 
communicated to the coordinators when the initial connections are made. The 
coordinators retain the commit point strengths of each node they are in direct 
communication with so that commit point sites can be efficiently selected during 
two-phase commits. Therefore, it is not necessary for the commit point strength to be 
exchanged between a coordinator and a node each time a commit occurs. 

See Also: 

■ "Specifying the Commit Point Strength of a Node" on page 33-1 
to learn how to set the commit point strength of a node 

■ Oracle Database Reference for more information about the 
initialization parameter COMMIT_POINT_STRENGTH 



Two-Phase Commit Mechanism 



Unlike a transaction on a local database, a distributed transaction involves altering 
data on multiple databases. Consequently, distributed transaction processing is more 
complicated, because the database must coordinate the committing or rolling back of 
the changes in a transaction as a self-contained unit. In other words, the entire 
transaction commits, or the entire transaction rolls back. 

The database ensures the integritv of data in a distributed transaction using the 
t*vo-phase commit mechanism. In the prepare phase, the initiating node in the 
transaction asks the other participating nodes to promise to commit or roll back the 
transaction. During the commit phase, the initiating node asks all participating nodes 
to commit the transaction. If this outcome is not possible, then all nodes are asked to 
roll back. 

All participating nodes in a distributed transaction should perform the same action: 
they should either all commit or all perform a rollback of the transaction. The database 
automatically controls and monitors the commit or rollback of a distributed 
transaction and maintains the integritv of the global database (the collection of 
databases participating in the transaction) using the two-phase commit mechanism. 
This mechanism is completely transparent, requiring no programming on the part of 
the user or application developer. 

The commit mechanism has the following distinct phases, wfhich the database 
performs automatically whenever a user commits a distributed transaction: 

Phase Description 

Prepare phase The initiating node, called the global coordinalor, asks 

participating nodes other than the commit point site to promise to 
commit or roll biick the transaction, even if there is a failure. If any 
node cannot prepare, the transaction is rolled back. 
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Phase Description 



Commit phase If all participants respond to the coordinator that thev are 

prepared, then the coordinator asks the commit point site to 
commit. After it commits, the coordinator asks all other nodes to 
commit the transaction. 



Forget phase The global coordinator forgets about the transaction. 

This section contains the following topics: 

■ Prepare Phase 

■ Commit Phase 

■ Forget Phase 



Prepare Phase 



The first phase in committing a distributed transaction is the prepare phase. In this 
phase, the database does not actually commit or roll back the transaction. Instead, aU 
nodes referenced in a distributed transaction (except the commit point site, described 
in the "Commit Point Site" on page 32-5) are told to prepare to commit. Bv preparing, a 
node: 

■ Records information in the redo logs so that it can subsequently either commit or 
roll back the transaction, regardless of intervening failures 

■ Places a distributed lock on modified tables, which prevents reads 

When a node responds to the global coordinator that it is prepared to commit, the 
prepared node promises to either commit or roll back the transaction later, but does not 
make a unilateral decision on whether to commit or roll back the transaction. The 
promise means that if an instance failure occurs at this point, the node can use the redo 
records in the online log to recover the database back to the prepare phase. 

Note: Queries that start after a node has prepared cannot access 
the associated locked data until all phases complete. The time is 
insignificant unless a failure occurs (see "Deciding How to Handle 
In-Doubt Transactions" on page 33-5), 



Types of Responses in the Prepare Phase 

When a node is told to prepare, it can respond in the following wavs: 

Response Meaning 

Prepared Data on the node has been modified bv a statement in the 

distributed transaction, and the node has successfully prepared. 

Read-only No data on the node has been, or can be, modified (only queried), 

I so no preparation is necessary 

' Abort The node cannot successfully prepare. 

Prepared Response When a node has successfully prepared, it issues a prepared 
message. The message indicates that the node has records of the changes in the online 
log, so it is prepared either to commit or perform a rollback. The message also 
guarantees that locks held for the transaction can survive a f aihire. 
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Read-Only Response When a node is asked to prepare, and the SQL statements affecting 
the database do not change any data on the node, the node responds with a read-only 
message. The message indicates that the node will not participate in the commit 
phase. 

There are three cases in which all or part of a distributed transaction is read-only: 

Case Conditions Consequence 

Partially read-only Any ot the following occurs: The read-only nodes recognize their 

^ , . , status when asked to prepare. Thev 

■ Only queries are issued at 

one or more nodes. 



give their local coordinators a 

read-only response. Thus, the 

No data is changed. commit phase completes faster 

„, 11 , 1 , , because the database eliminates 

Chanaes roiled back due , , , r i 

... r. , read-onlv nodes trom subsequent 

to trieeers tirme or . -' ^ 

°°. , . , °. processing, 
constraint violations. 



Completely read-only All of following occur: All nodes recognize that they are 

with prepare phase m j 4- i. read-only during prepare phase, so 

■ JNo data cnanfies, 'l i ■ j t^i 

° no commit phase IS required, ihe 

■ Transaction is not started global coordinator, not knowing 
with SET TRANSACTIOH whether all nodes are read-only, 
READ ONLY statement. must still perform the prepare phase. 

Completely read-only All of following occur: Only queries are allowed in the 

without two- phase ,,r , , transaction, so global coordinator 

■ JNo data changes, , .,. r . < 
commit " does nor have to perform two-phase 

■ Transaction is started with commit Changes by other 

SET TRANSACTIOH transactions do notdegrade global 

REM) ONLY statement. transaction-level read consistency 

because of global SCN coordination 

I among nodes. The transaction does 

not use undo segments. 



Note that if a distributed transaction is set to read-only, then it does not use undo 
segments. If many users connect to the database and their transactions are no! set to 
READ ONLY, then they allocate undo space even if they are only performing queries. 

Abort Response When a node cannot successfully prepare, it performs the following 
actions: 

1. Releases resources currently held bv the transaction and rolls back the local 
portion of the transaction, 

2. Responds to the node that referenced it in the distributed transaction with an abort 
message. 

These actions then propagate to the other nodes involved in the distributed transaction 
so that they can roll back the transaction and guarantee the integrity of the data in the 
global database. This response enforces the primary rule of a distributed transaction: 

all nodes involved in ihe transaction cither all commit or all roll back the transaction at the 
same logical time. 

Steps in the Prepare Phase 

To complete the prepare phase, each node excluding the commit point site performs 
the following steps: 

1. The node requests that its descendants, that is, the nodes subsequently referenced, 
prepare to commit. 
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2. The node checks to see whether the transaction changes data on itself or its 
descendants. If there is no cliange to tiie data, then the node skips the remaining 
steps and returns a read-only response (see "Read-Only Response" on page 32-9), 

3. The node allocates the resources it needs to commit the transaction if data is 
changed. 

4. The node saves redo records corresponding to changes made by the transaction to 
its redo log. 

5. The node guarantees that locks held for the transaction are able to survive a 
failure. 

6. The node responds to the initiating node with a prepared response (see "Prepared 
Response" on page 32-8) or. if its attempt or the attempt of one of its descendents 
to prepare was unsuccessful, with an abort response (see "Abort Response" on 
page 32-9). 

These actions guarantee that the node can subsequently commit or roll back the 
transaction on the node. The prepared nodes then wait until a COMMIT or ROLLBACK 
request is received from the global coordinator. 

After the nodes are prepared, the distributed transaction is said to be in-doubt (see 
"In-Doubt Transactions" on page 32-11). It retains in-doubt status until all changes are 
either committed or rolled back. 



Commit Phase 



The second phase in committing a distributed transaction is the commit phase. Before 
this phase occurs, aU nodes other than the commit point site referenced in the 
distributed transaction have guaranteed that they are prepared, that is, thev have the 
necessary resources to commit the transaction. 

Steps in the Commit Phase 

The commit phase consists of the following steps: 

1 . The global coordinator instructs the commit point site to commit. 

2. The commit point site commits. 

3. The commit point site informs the global coordinator that it has committed. 

4. The global and local coordinators send a message to all nodes instructing them to 
commit the transaction. 

5. At each node, the database commits the local portion of the distributed transaction 
and releases locks. 

6. At each node, the database records an additional redo entry in the local redo log, 
indicating that the transaction has committed. 

7. The participating nodes notify the global coordinator that they have committed. 

When the commit phase is complete, the data on all nodes of the distributed system is 
consistent. 

Guaranteeing Giobal Database Consistency 

Each committed transaction has an associated system change number (SCN) to 
uniquely identify the changes made by the SQL statements within that transaction. 
The SCN functions as an internal timestamp that uniquely identifies a committed 
version of the database. 
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In a distributed svstem, the SCNs of com. mimic a ting nodes are coordinated when all of 
the following actions occur: 

■ A connection occurs using the path described hy one or more database links 

■ A distributed SQL statement executes 

■ A distributed transaction commits 

Among other benefits, the coordination of SCNs among the nodes of a ttistributett 
system ensures global read-consistencv at both the statement and transaction level. If 
necessary, global time-based recover}' can also be completed. 

During the prepare phase, the database determines the highest SCN at all nodes 
involved in the transaction. The transaction then commits with the high SCN at the 
commit point site. The commit SCN is then sent to all prepared nodes with the commit 
decision. 

See Also: "Managing Read Consistency" on page 33-19 for 
information about managing time lag issues in read consistency 



Forget Phase 



After the participating nodes notify the commit point site that they have committed, 
the commit point site can forget about the transaction. The following steps occur: 

1. After receiving notice from the global coordinator that all nodes have committed, 
the commit point site erases status information about this transaction. 

2. The commit point site informs the global coordinator that it has erased the status 
inform iiti on. 

3. The global coordinator erases its own information about the transaction. 



In-Doubt Transactions 



The two-phase commit mechanism ensures that all nodes either commit or perform a 
rollback together What happens if anv of the three phases fails because of a svstem or 
network error? The transaction becomes in-doubt. 

Distributed transactions can become in-doubt in the following wavs: 

■ A server machine running Oracle Database software crashes 

■ A netivork connection between tivo or more Oracle Databases involved in 
distributed processing is disconnected 

■ An unhandled software error occurs 

The RECO process automatically resolves in-doubt transactions when the machine, 
network, or software problem is resolved. Until RECO can resolve the transaction, the 
data is locked for both reads and writes. The database blocks reads because it cannot 
determine which version of the data to display for a querv. 

This section contains the foUowing topics: 

■ Automatic Resolution of In-Doubt Transactions 

■ Manual Resolution of In-Doubt Transactions 

■ Relevance of System Change Numbers for In-Doubt Transactions 
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Automatic Resolution of In-Doubt Transactions 

In the majoritv of cases, the database resolves the in-doiibt transaction automaticaUy. 
Assume that there are two nodes, local and remote, in the following scenarios. The 
local node is the commit point site. User scott connects to local and executes and 
commits a distributed transaction that updates local and remote. 

Failure During the Prepare Phase 

Figure 32-5 illustrates the sequence of events when there is a failure during the 
prepare phase of a distributed transaction: 

Figure 32-5 Failure During Prepare Phase 



COMMIT POIHT STRENGTH = 20D 




' All databases perform 
rollback 



Q Asks REMOTE to prepare 



o 



Crashes before giving 
prepare response 




COMMIT POIHT STREHGTH = 100 



fh Issues distributed 



transaction 



The following steps occur: 

1. User SCOTT connects to Local and executes a distributed transaction. 

2. The global coordinator, which in this example is also the commit point site, 
requests all databases other than the commit point site to promise to commit or 
roll back when told to do so. 

3. The remote database crashes before issuing the prepare response back to local. 

4. The transaction is ultimately rolled back on each database by the RECO process 
w^hen the remote site is restored. 

Failure During the Commit Piiase 

Figure 32-6 illustrates the sequence of events when there is a failure during the 
commit phase of a distributed transaction: 
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Figure 32-6 Failure During Commit Phase 

^3 All databases commll after 
network restored 
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Q Asks REMOTE to prepare 
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The following steps occur: 

1. User Scott connects to local and executes a distributed transaction. 

2. Tlie global coordinator, which in this case is also the commit point site, requests all 
databases other than the commit point site to promise to commit or roll back when 
told to do so. 

3. The commit point site receives a prepared message irom remote saving that it 
vv' ill commit. 

4. The commit point site commits the transaction locally, then sends a commit 
message to remote asking it to commit. 

5. The remote database receives the commit message, but cannot respond because 
of a network failure. 

6. The transaction is ultimately committed on the remote database by the RECO 
process after the network is restored. 

See Also: "Deciding How to Handle In-Doubt Transactions" on 
page 33-5 for a description of failure situations and how the 
database resolves intervening failures during two-phase commit 

Manual Resolution of In-Doubt Transactions 

You should only need to resolve an in-doubt transaction in the following cases: 

■ The in-doubt transaction has locks on critical data or undo segments. 

■ The cause of the machine, network, or software failure caruiot be repaired quickly. 

Resolution of in-doubt transactions can be complicated. The procedure requires that 
you do the following: 

■ Identify the transaction identification number for the in-doubt transaction. 

■ Query the DBA_2PC_PE]srDING and DBA_2PC_NEIGHB0RS views to determine 
whether the databases involved in the transaction have committed. 

■ If necessary, force a commit using the COMMIT FORCE statement or a rollback 

using the ROLLBACK FORCE statement. 
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See Also: The following sections explain how to resolve in-doubt 
transactions: 

■ "Deciding How to Handle In-Doubt Transactions" on page 33-5 

■ "ManuaUy Overriding In-Doubt Transactions" on page 33-8 

Relevance of System Change Numbers for In-Doubt Transactions 

A system change number (SCN) is an internal timestamp for a committed version of 
the datiibase. The Oracle Database server uses the SCN clock value to guarantee 
transaction consistencv. For example, when a user commits a transaction, the database 
records an SCN for this commit in the redo log. 

The database uses SCNs to coordinate distributed transactions among different 
databases. For example, the database uses SCNs in the following way: 

1. An application establishes a connection using a database link, 

2. The distributed transaction commits with the highest global SCN among all the 
databases involved, 

3. The commit global SCN is sent to all databases involved in the transaction, 

SCNs are important for distributed transactions because thev function as a 
svnchronized commit timestamp of a transaction, even if the transaction fails. If a 
transaction becomes in-doubt, an administrator can use this SCN to coordinate 
changes made to the global database. The global SCN for the transaction commit can 
also be used to identifv the transaction later, for example, in distributed recovery. 

Distributed Transaction Processing: Case Study 

In this scenario, a company has separate Oracle Database senders, sales . acme . com 
and warehouse . acme . com. As users insert sales records into the sales database, 
associated records are being updated at the warehouse database. 

This case study of distributed processing illustrates: 

The definition of a session tree 

How a commit point site is determined 

When prepare messages are sent 

When a transaction actually commits 

What information is stored locallv about the transaction 

Stage 1: Client Application Issues DML Statements 

At the Sales department, a salesperson uses SQL'Plus to enter a sales order and then 
commit it. The application issues a number of SQL statements to enter the order into 
the sales database and update the inventory in the warehouse database: 

COMMECT scottSsales, acme, com ...; 

IHSEET IHTO orders , , . ; 

UPDATE invent or y Swar ehous e . acme , com ,.,; 

IHSEET IHTO orders , , . ; 

UPDATE invent ory@war ehouse . acme , com ,.,; 

COMMIT; 

These SQL statements are part of a single distributed transaction, guaranteeing that all 
issued SQL statements succeed or fail as a unit. Treating the statements as a unit 
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prevents the possibilit}" of an order being placed and then inventory not being 
updated to reflect the order. In effect, the transaction guarantees the consistency of 
data in the global database. 

As each of the SQL statements in the transaction executes, the session tree is defined, 
as shown in Figure 32-7. 



Figure 32-7 Defining the Session Tree 



INSERT INTO orders . . . ; 

UPDATE inventory @ warehouse. . . ; 

INSERT INTO orders . . . ; 

UPDATE inventory @ warehouse. . . ; 

COMMIT; 



SALES.ACME.COM 



•o 
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^1 Global Coordinator 
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WAREHOUSE.ACME.COIW □ Client 

Note the following aspects of the transaction: 

■ An order entry application running on the sales database initiates the 
transaction. Therefore, sales . acme . com is the global coordinator for the 
distributed transaction, 

■ The order entrv application inserts a new sales record into the sales database 
and updates the inventory at the warehouse. Therefore, the nodes 

sales . acme . com and warehouse . acme . com are both database servers, 

■ Because sales . acme . com updates the inventory, it is a client of 

warehouse . acme . com. 

This stage completes the definition of the session tree for this distributed transaction. 
Each node in the tree has acquired the necessar}' data locks to execute the SQL 
statements that reference local data. These locks remain even after the SQL statements 
have been executed until the two-phase commit is completed. 

Stage 2: Oracle Database Determines Commit Point Site 

The database determines the commit point site immediatelv following the COMMIT 
statement sales . acme . com, the global coordinator, is determined to be the commit 
point site, as shown in Figure 32-8, 

See Also: "Commit Point Strength" on page 32-6 for more 
information about how the commit point site is determined 
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Figure 32-8 Determining the Commit Point Site 
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Stage 3: Global Coordinator Sends Prepare Response 

The prepare stage involves the following steps: 

1 . After the database determines the commit point site, the global coordinator sends 
the prepare message to all directiv referenced nodes of the session tree, excluding 
the commit point site. In this example, warehouse . acme . com is the onlv node 
asked to prepare. 

2. Node warehouse . acme . com tries to prepare. If a node can guarantee that it can 
commit the locallv dependent part of the transaction and can record the commit 
information in its local redo log, then the node can successfully prepare. In this 
example, onlv warehouse . acme . com receives a prepare message because 
sales . acme . com is the commit point site. 

3. Node warehouse . acme . com responds to sales . acme . com with a prepared 
message. 

As each node prepares, it sends a message back to the node that asked it to prepare. 
Depending on the responses, one of the following can happen: 

■ If any of the nodes asked to prepare responds with an abort message to the global 
coordinator, then the global coordinator tells all nodes to roll back the transaction, 
and the operation is completed, 

■ If all nodes asked to prepare respond w^ith a prepared or a read-only message to 
the global coordinator, that is, they have successfully prepared, then the global 
coordinator asks the commit point site to commit the transaction. 
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Figure 32-9 Sending and Acknowledging the Prepare Message 
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Stage 4: Commit Point Site Commits 



The committing of the transaction by the commit point site involves the following 
steps: 

1. Node sales . acme . com, receiving acknowledgment that 

warehouse . acme . com is prepared, instructs the commit point site to commit the 
transaction. 

2. The commit point site now commits the transaction locally and records this fact in 
its local redo log. 

Even if warehouse . acme . com has not vet committed, the outcome of this transaction 
is predetermined. In other words, the transaction will be committed at all nodes even if 
the ability of a given node to commit is delayed. 

Stage 5: Commit Point Site Informs Global Coordinator of Commit 

This stage involves the following steps: 

1 . The commit point site tells the global coordinator that the transaction has 
committed. Because the commit point site and global coordinator are the same 
node in this example, no operation is required. The commit point site knows that 
the transaction is committed because it recorded this fact in its online log, 

2. The global coordinator confirms that the transaction has been committed on all 
other nodes involved in the distributed transaction. 

Stage 6: Global and Local Coordinators Tell All Nodes to Commit 

The committing of the transaction by all the nodes in the transaction involves the 
following steps: 

1 . After the global coordinator has been informed of the commit at the commit point 
site, it tells all other directlv referenced nodes to commit. 

2. In turn, any local coordinators instruct their servers to commit, and so on. 
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3. Each node, including tlie global coordinator, commits the transaction and records 
appropriate redo log entries locally. As each node commits, the resource locks that 
were being held locally for that transaction are released. 

In Figure 32-10. sales . acme . com, which is both the commit point site and the global 
coordinator, has already committed tlie transaction locally, sales now instructs 

warehouse . acme . com to commit the transaction. 



Figure 32-10 Instructing Nodes to Commit 
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Stage 7: Global Coordinator and Commit Point Site Complete the Commit 

The completion of the commit of the transaction occurs in the following steps: 

1. After all referenced nodes and the global coordinator have committed the 
transaction, the global coordinator informs the commit point site of this fact 

2. The commit point site, which has been waiting for this message, erases the status 
information about this distributed transaction. 

3. The commit point site informs the global coordinator that it is finished. In other 
words, the commit point site forgets about committing the distributed transaction. 
This action is permissible because all nodes involved in the two-phase commit 
have committed the transaction successfully, so they will never have to determine 
its status in the future. 

4. The global coordinator finalizes the transaction by forgetting about the transaction 
itself. 

After the completion of the COMMIT phase, the distributed transaction is itself 
complete. The steps described are accomplished automatically and in a fraction of a 
second. 
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In this chapter: 

Specif\'ing the Commit Point Strength of a Node 

Naming Transactions 

Viewing Information About Distributed Transactions 

Deciding How to Handle In-Doubt Transactions 

Manually Overriding In-Doubt Transactions 

Purging Pending Rows from the Data Dictionary 

Manually Committing an In-Doubt Transaction: Example 

Data Access Failures Due to Locks 

Simulating Distributed Transaction Failure 

Managing Read Consistency 

Specifying the Commit Point Strengtii of a Node 

The database with the highest commit point strength determines which node commits 
first in a distributed transaction. When specifving a commit point strength for each 
node, ensure that the most critical server will be non-blocking if a failure occurs 
during a prepare or commit phase. The C0MMIT_P0INT_3TRENGTH initialization 
parameter determines the commit point strength of a node. 

The default value is operating sv stem -de pendent. The range of values is anv integer 
from to 255, For example, to set the commit point strength of a database to 200, 
include the following hne in the database initialization parameter file: 

COMHIT_POIHT_STEENGTH = 200 

The commit point strength is onlv used to determine the commit point site in a 
distributed transaction. 

When setting the commit point strength for a database, note the following 
consi derations: 

■ Because the commit point site stores information about the status of the 
transaction, the commit point site should not be a node that is frequentlv 
unreliable or unavailable in case other nodes need iniormalion about transaction 
status. 

■ Set the commit point strength for a database relative to the amount of critical 
shared data in the database. For example, a database on a mainframe computer 
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usiiiillv shares more data among users than a dat.ibase on a PC. Therefore, set the 
commit point strength of the mainframe to a liigher value than the PC, 

See Also: "Commit PointSite" on page 32-5 for a conceptual 
oven'iew of commit points 



Naming Transactions 



You can name a transaction. This is useful for identifying a specific distributed 
transaction and replaces the use of the COMMIT COMMENT statement for this purpose. 

To name a transaction, use the SET TRANSACTION. . .NAME statement. For example: 

SET TRMSACTIOH ISOLATIOM LEVEL SERIALIZABLE 
IfiME 'update inventory checkpoint 0'; 

This example shows that the user started a new transaction with isolation level equal 

to SERIALIZABLE and named it 'update inventory checkpoint 0'. 

For distributed transactions, the name is sent to participating sites when a transaction 
is committed. If a COMMIT COMMENT exists, it is ignored when a transaction name 
exists. 

The transaction name is displayed in the NAME column of the VgTRANSACT ION view, 
and in the THAN_COMMENT field of the DBA_2PC_PEND1NG view when the 
transaction is committed. 

Viewing Information About Distributed Transactions 

The data dictionary of each database stores information about all open distributed 
transactions. You can use data dictionar\' tables and views to gain information about 
the transactions. This section contains the following topics: 

■ Determining the ID Number and Status of Prepared Transactions 

■ Tracing the Session Tree of In-Doubt Transactions 

Determining the ID Number and Status of Prepared Transactions 

The following view shows the database links that have been defined at the local 
database and stored in the data dictionary: 

View Purpose 

' -I 

DBA_2 PC_PEMDIHG Lists aU In-doubt distributed transactions. The view is empty 

I until populated by an in-doubt transaction. After the transaction 

I is resolved, the view is purged. 

i . 

Use this view to determine the global commit number for a particular transaction ID. 
You can use this global commit number when manuaUy resolving an in-doubt 
transaction. 

The following table shows the most relevant columns (for a description of aU the 
columns in the view, see Oracle Database Reference): 
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Table 33-1 DBA 2PC PENDING 



Column 


Description 


LOCAL_TRAM_ID 


Local transaction identifier in the format integer. integer. integer. 




Note; When the LOCAL_TRAN_ID and the GLOBAL_TRAN_ID 




for a connection are the same, the node is the global coordinator 




of the transaction. 


GLOBAL_TRAN_ID 


Global database identifier in the format 




globat_db_name.db_hex_id.tocal_tran_id, where db_hex_id is an 
eight- character hexadecimal value used to uniquely identify the 




database. This common transaction ID is the same on every 




node for a distributed transaction. 




Note: When the LOCAL_TRAN_ID and the GLOBAL_TRAN_ID 




for a connection are the same, the node is the global coordinator 




of the transaction. 


STATE 


STATE can have the following values: 




■ Collecting 




This category normally applies only to the global 




coordinator or local coordinators. The node is currently 




collecting information from other database servers before it 




can decide whether it can prepare. 




■ Prepared 




The node has prepared and may or may not have 




acknowledged this to its local coordinator with a prepared 




message. However, no commit request has been received. 




The node remains prepared, holding any local resource 




locks necessary for the transaction to commit. 




■ Committed 




The node [any type) has committed the transaction, but 




other nodes involved in the transaction may not have done 




the same. That is, the transaction is still pending at one or 




more nodes. 




■ Forced Commit 




A pending transaction can be forced to commit at the 




discretion of a database administrator. This entry occurs if a 




transaction is manually committed at a local node. 




■ Forced termination (rollback) 




A pending transaction can be forced to roll back at the 




discretion of a database administrator This entry occurs if 




this transaction is manually rolled back at a local node. 


MIXED 


YES means that part of the transaction was committed on one 




node and rolled back on another node. 


TRAN_COMMENT 


Transaction comment or, if using transaction naming, the 




transaction name is placed here when the transaction is 




committed. 


HOST 


Name of the host machine. 


COMMITtt 


Global com.m.it number for committed transactions. 



Execute the following script, named pending_txn_script, to query pertinent 
information in DBA_2PC_PENDING (sample output included): 



COL LOCAL_TRAN_ID FORMftT A13 
COL GLOBAL_TRAH_ID FORMAT A30 
COL STATE FORMAT A8 
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COL MIXED FOEMAT A3 
COL HOST FORMAT AlO 
COL COMHIT# FORMAT AlO 

SELECT LOCAL_TRM_ID, GLOBAL_TRAF_ID, STATE, MIXED, HOST, COMMITtt 

FROM DBA_2PC_PEHDIHG 
/ 



SQL> @pending_txn_Ecript 
LOCAL TRAN ID GLOBAL TRAN ID 



STATE 



MIX HOST 



COMMITI 



1.15.870 



HQ .ACME.COM.ef 192da4 .1 . 15 . 870 conmit no dlsunl83 1154S 



This output indicates that local transaction 1.15.370 has been committed on this 
node, but it may be pending on one or more other nodes. Because LOCAL_TRAN_ID 
and the local part of GLOBAL_TRAN_ID are the same, the node is the global 
coordinator of the transaction. 

Tracing the Session Tree of In-Doubt Transactions 

The following view shows which in-doubt transactions are incoming from a remote 
client and which are outgoing to a remote server: 



View 



Purpose 



DBA_2 PC_NEIGfIBORS Lists all incoming (from remote client) iind outgoing (to remote 
server) in-doubt distributed triinsactions. It also indicates 
whether the local node is the commit point site in the 

triinsiiction. 



The view is empty until populated by an In-doubt transaction. 
After the transaction is resolved, the view is purged. 



When a transaction is in-doubt, you may need to determine which nodes performed 
which roles in the session tree. Use to this view to determine: 

■ All the incoming and outgoing connections for a given transaction 

■ Whether the node is the commit point site in a given transaction 

■ Whether the node is a global coordinator in a given transaction (because its local 
transaction ID and global transaction ID are the same) 

The following table shows the most relevant columns (for an account of all the 
columns in the view, see Oracle Database Reference): 

Table 33-2 DBA_2PC_NEIGHB0RS 
Column Description 



LOCAL_TRAH_ID Local transaction identifier with the format 

ifi tcger . in tcgcr. in tegcr . 

Note; When LOCAL_TRAM_ID and 

GL0BAL_TRAM_ID.DBA_2PC_PENDING for a connection are the 
same, the node is the global coordinator of the transaction. 



IN OUT 



IN for incoming transactions; OUT for outgoing transactions. 



DATABASE 



For incoming transactions, the name of the client database that 
requested information from this local node; for outgoing 
transactions, the name of the database link used to access 
information on a remote server 
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Table 33-2 (Cont.) DBA_2PC_NEIGHB0RS 



Column 



Description 



DBUSER OWNER 



INTERFACE 



For incoming transactions, the local account used to connectby 
the remote database link; for outgoing transactions, the owner 
of the database link. 

C is a commit message; H is either a message indicating a 
prepared state or a request for a read-onlv commit. 

When IH_OUT is OUT, C means that the child at the remote end 
of the connection is the commit point site and knows whether to 
commit or terminate. H means that the local node is informing 
the remote node that it is prepared. 

When IN_GUT is IN, C means that the local node or a database 
at the remote end of an outgoing connection is the commit point 
site. H means that the remote node is inform.ing the local node 
that it is prepared. 



Execute the following script, named neighbors_script, to query pertinent 
information in DBA_2PC_PENDING (sample output included): 

COL LOCAL_TRM_ID FORMAT A13 

COL IN_OUT FOHMftT AS 

COL DATABASE FORMAT A25 

COL DBUSER_OWNER FOEMAT A15 

COL INTERFACE FORMAT A3 

SELECT LOCAL_TRAM_ID, IH_OUT, DATABASE, DBUSERJifflER, INTERFACE 

FROM DBA_2PC_NEIGHB0RS 
/ 

SeL> CONMECT SYS@hq.acme.com AS SYSDBA 
SQL> @neighbors_sciript 



LOCAL TRAM ID IN OUT DATABASE 



DBUSER OWNER 



INT 



1.15.870 



out 



SALES. ACME. COM 



SYS 



This output indicates that the local node sent an outgoing request to remote sender 
sales to commit transaction 1 . 15 . 870. If sales committed the transaction but no 
other node did, then vou know that sales is the commit point site, because the 
commit point site always commits first. 

Deciding How to Handle In-Doubt Transactions 

A transaction is in-doubt when there is a failure during anv aspect of the two-phase 
commit. Distributed transactions become in-doubt in the following ways: 

■ A server machine running Oracle Database software crashes 

■ A netivork connection beb,veen two or more Oracle Databases involved in 
distributed processing is disconnected 

■ An unhandled software error occurs 

See Also: "In-Doubt Transactions" on page 32-11 for a conceptual 
over\'iew of in-doubt transactions 
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YoLL can niiinuallv force the commit or rollback of a local, in-doiibt distributed 
transaction. Because this operation can generate consistency problems, perform it only 
when specific conditions exist. 

This section contains the following topics: 

■ Discovering Problems with a Two-Phase Commit 

■ Determining Whether to Perform a Manual Override 

■ Analyzing the Transaction Data 

Discovering Problems with a Two-Phase Commit 

The LLser application that commits a distributed transaction is informed of a problem 
bv one of the following error messages: 

OEA-02050: transaction ID rolled back, 

some remote dbs may be in-doiibt 
OEA-02053: transaction ID committed, 

some remote dbs may be in-doiibt 
OEA-02054: transaction ID in-doubt 

A robust application should save information about a transaction if it receives anv of 
the preceding errors. This information can be used later if manual distributed 
transaction recovery is desired. 

No action is required by the administrator of any node that has one or more in-doubt 
distributed transactions due to a netivork or system failure. The automatic recovery 
features of the database transparentlv complete any in-doubt transaction so that the 
same outcome occurs on all nodes of a session tree (that is, all commit or all roll back) 
after the network or system failure is resolved. 

In extended outages, however, you can force the commit or rollback of a transaction to 
release any locked data. Applications must account for such possibilities. 

Determining Whether to Perform a Manuai Override 

Override a specific in-doubt transaction manually oiili/ when one of the following 
conditions exists: 

■ The in-doubt transaction locks data that is required bv other transactions. This 
situation occurs when the ORA-015 91 error message interferes with user 
transactions. 

■ An in-doubt transaction prevents the extents of a undo segment from being used 
by other transactions. The first portion of the local transaction ID of an in-doubt 
distributed transaction corresponds to the ID of the undo segment, as listed bv the 
data dictionary view DBA_2PC_PEWDIWG. 

■ The failure preventing the two-phase commit phases to complete cannot be 
corrected in an acceptable time period. Examples of such cases include a 
telecommunication neh,vork that has been damaged or a damaged database that 
requires a long recovery time, 

Normallv, vou should make a decision to locally force an in-doubt distributed 
transaction in consultation with administrators at other locations, A wrong decision 
can lead to database inconsistencies that can be difficult to trace and that you must 
manuallv correct. 
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If none of these conditions apply, always allow the automatic recoven" features of the 
database to complete the transaction. If any of these conditions are met, however, 
consider a local override of the in-doubt transaction. 



Analyzing the Transaction Data 



If you decide to force the transaction to complete, analyze available information with 
the following goals in mind. 

Find a Node tliat Committed or Rolled Back 

Use theDBA_2PC_PEHDIHG view to find a node that has either committed or rolled 
back the transaction. If vou can find a node that has already resolved the transaction, 
then you can follow the action taken at that node. 

Look for Transaction Comments 

See if any information is given in the TRAN_COMMENT column of DBA_2PC_P ENDING 
for the distributed transaction. Comments are included in the COMMENT clause of the 
COMMIT statement, or if transaction naming is used, the transaction name is placed in 
the TRAH_COMMENT field when the transaction is committed. 

For example, the comment of an in-doubt distributed transaction can indicate the 
origin of the transaction and what tj'pe of transaction it is: 

COMMIT COMMENT 'Finance/Accts_pay/Trans_type lOB ' ; 

The SET TRANSACTION. . . NAME statement could also have been used (and is 
preferable) to provide this information in a transaction name. 

See Also: "Naming Transactions" on page 33-2 

Look for Transaction Advice 

See if any information is given in the ADVICE column of DBA_2PC_PENDING for the 
distributed transaction. An application can prescribe advice about whether to force the 
commit or force the rollback of separate parts of a distributed transaction with the 

ADVISE clauseof the ALTER SESSION statement. 

The advice sent during the prepare phase to each node is the advice in effect at the 
time the most recent DML statement executed at that database in the current 
transaction. 

For example, consider a distributed transaction that moves an employee record from 
the emp table at one node to the emp table at another node. The transaction can protect 
the record— even when administrators independently force the in-doubt transaction at 
each node— by including the following sequence of SQL statements: 

ALTER SESSION ADVISE COMMIT; 

INSERT IHTO empShq . . . ; /'advice to commit at HQ */ 

ALTER SESSION ADVISE ROLLBACK; 

DELETE FROM empSsales ... ; /'advice to roll back at SALES*/ 

ALTER SESSION ADVISE HDTHING; 

If VOU manually force the in-doubt transaction following the given advice, the worst 
that can happen is that each node has a copy of the employee record; the record cannot 
disappear 
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Use the COMMIT or ROLLBACK statement with the FORCE option and a text string that 
indicates either the local or global transaction ID of the in-doubt transaction to 
commit, 

Note: In all examples, the transaction is committed or rolled back 
on the local node, and the local pending transaction table records a 
value of forced commit or forced termination for the STATE column 
the row for this transaction. 

This section contains the following topics: 

■ Manually Committing an In-Doubt Transaction 

■ Manually Rolling Back an In-Doubt Transaction 

Manually Committing an In-Doubt Transaction 

Before attempting to commit the transaction, ensure that you have the proper 
privileges. Note the following requirements: 

User Committing the Transaction Privilege Required 

You FORCE TRAMSACTION 

i Another user FORCE AMY TRAMSACTION 

Committing Using Oniy the Transaction ID 

The following SQL statement commits an in-doubt transaction: 

COMMIT FORCE ' transaction_id' ; 

The variable traiisacfion_id is the identifier of the transaction as specified in either the 

LOCAL_TEAW_ID or GLOBAL_TRAN_ID columns of the DBA_2 PC_PENDING data 

dictionary view. 

For example, assume that vou querv DBA_2PC_PENDING and determine that 

LOCAL_TEAW_ID for a distributed transaction is 1 : 45 .13. 

You then issue the following SQL statement to force the commit of this in-doubt 
transaction: 

COMMIT FORCE '1.45.13'; 

Committing Using an SCN 

Optionally, you can specify the SCN for the transaction when forcing a transaction to 
commit This feature lets you commit an in-doubt transaction with the SCN assigned 
when it was committed at other nodes. 

Consequently, you maintain the syncturonized commit time of the distributed 
transaction even if there is a failure. Specify an SCN only when you can determine the 
SCN of the same transaction already committed at another node. 

For example, assume you want to manually commit a transaction with the following 
global transaction ID: 

SALES. ACHE. COM. 55dlc563. 1.93. 29 
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First, querv the DBA_2PC_PENDING view of a remote database also involved with the 
transaction in question. Note the SCN used for the commit of the transaction at that 
node. Specify the SCN when committing the transaction at the local node. For 
example, if the SCN is 829381993, issue: 

COMMIT FORCE 'SALES .ACME.COM. 55dlc563 .1 . 93 . 29 ' , 829381993; 

See Also: Oracle Database SQL Language Reference for more 
information about using the COMMIT statement 

Manually Rolling Back an In-Doubt Transaction 

Before attempting to roll back the in-doubt distributed transaction, ensure that you 
have the proper privileges. Note the following requirements: 

User Committing the Transaction Privilege Required 

You FORCE TRAMSACTION j 



Another user , FORCE ANY TRANSACTION 



The following SQL statement rolls back an in-doubt transaction: 

ROLLBACK FORCE ' trdns3ction_id' ; 

The variable transaction_id is the identifier of the transaction as specified in either the 

LOCAL_TRAN_ID or GLOBAL_TRAN_ID columns of the DBA_2 PC_PEHDING data 

dictionary view. 

For example, to roll back the in-doubt transaction with the local transaction ID of 
2.9.4, use the following statement: 

ROLLBACK FORCE '2.9.4'; 

Note: You cannot roll back an in-doubt transaction to a savepoint. 



See Also: Oracle Database SQL Language Reference for more 
information about using the ROLLBACK statement 



Purging Pending Rows from the Data Dictionary 



Before RECO recovers an in-doubt transaction, the transaction appears in 

DBA_2PC_PENDING. STATE as COLLECTING, COMMITTED, or PREPARED. If you force 

an in-doubt transaction using COMMIT FORCE or ROLLBACK FORCE, then the states 
FORCED COMMIT or FORCED ROLLBACK may appear 

Automatic recovery normallv deletes entries in these states. The onlv exception is 
when recover}' discovers a forced transaction that is in a state inconsistent with other 
sites in the transaction. In this case, the entrv can be left in the table and the MIXED 
column in DBA_2PC_P ENDING has a value of YES, These entries can be cleaned up 
with the DBMS_TRANSACTION. PURGE_MIXED procedure. 

If automatic recoverv is not possible because a remote database has been permanently 
lost, then recovery cannot identify the re-created database because it receives a new 
database ID when it is re-created. In this case, you must use the 

PURGE_LOST_DB_ENTRY procedure in the DBMS.TRANSACTION package to clean up 
the entries. The entries do not hold up database resources, so there is no urgency in 
cleaning them up. 
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See Also: Oracle Database PL/SQL Packages and Types Reference for 
more information about the DBMS_TRANSACT I ON package 

Executing the PURGE_LOST_DB_ENTRY Procedure 

To manually remo\'e an entr}' from the data dictionary, use the following syntax 
(where lrans_iii is the identifier for the transaction): 

DBMS_TRM3ACTI0N.PUEGE_L0ST_DB_ENTRY( ' fcrans_id' } ; 

For example, to purge pending distributed transaction 1.44.99, enter the following 
statement in SQL 'Plus: 

EXECUTE DBMS_TRM3ACTI0H.PUEGE_L0ST_DB_ENTRY[ '1.44.99' }; 

Execute this procedure only if significant reconfiguration has occurred so that 
automatic recovery cannot resolve the transaction. Examples include: 

■ Total loss of the remote database 

■ Reconfiguration in software resulting in loss of tivo-phase commit capability 

■ Loss of information from an external transaction coordinator such as a TPMonitor 

Determining Wlien to Use DBIUIS.TRANSACTiON 

The following tables indicates what the various states indicate about the distributed 
transaction what the administrator's action should be: 



STATE 
Column 


State of Global 
Transaction 


State of Local 
Tratisaction 


Normal Action 


Alternative Action 


Collecting 


Rolled back 


Rolled back 


None 


PURGE_LOST_DB_EN 

TRY (only if 
autorecovery cannot 
resolve transaction) 


Committed 


Committed 


Committed 


None 


PURGE_LOS T_DB_EH 
TRY (only if 
autorecovery cannot 
resolve transaction) 


Prepared 


Unknown 


Prepared 


None 


Force commit or 
rollback 


Forced 
commit 


Unknown 


Committed 


None 


PURGE_LOS T_DB_EH 
TRY (only if 
autorecovery cannot 
resolve transaction) 


Forced 
rollback 


Unknown 


Rolled back 


None 


PURGE_LOST_DB_EN 

TRY (only if 
autorecovery cannot 

resolve transaction) 


Forced 
commit 


Mixed 


Committed 


Manually remove 
inconsistencies 
then use 
PURGE_MIXED 




Forced 
rollback 


Mixed 


Rolled back 


Manually remove 
inconsistencies 
then use 

PURGE_MIXED 





33-10 Oracle Database Administrator's Guide 



Manjally Commuting an In-Doubt Transaclion: Example 



lanually Committing an In-Doubt Transaction: Example 

Figure 33-1, illiistriites a failure during the commit of a distributed transaction. In this 
ftiilure case, the prepare phase completes. During the commit phase, however, the 
commit confirmation of the commit point site never reaches the global coordinator, 
even though the commit point site committed the transaction, Inventorv data is locked 
and cannot be accessed because the in-douht transaction is critical to other 
transactions. Further, the locks must he held until the in-doubt transaction either 
commits or rolls back. 

Figure 33-1 Example of an In-Doubt Distributed Transaction 
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You can manually force the local portion of the in-doubt transaction by following the 
steps detaUed in the following sections: 

Step 1: Record User Feedback 

Step 2: Query DBA_2PC_PEND1NG 

Step 3: Query DBA_2PC_NElGHBORS on Local Node 

Step 4: Querying Data Dictionary Views on All Nodes 

Step 5: Commit the In-Doubt Transaction 

Step 6: Check for Mixed Outcome Using DBA_2PC_PEND1NG 



Step 1: Record User Feedback 



The users of the local database system that conflict with the locks of the in-doubt 
transaction receive the following error message: 

DEA-01591: lock held by in-doubt distributed transaction 1,21,17 

In this case, 1 . 21 , 17 is the local transaction ID of the in-doubt distributed 
transaction. You should request and record this ID number from users that report 
problems to identify which in-doubt transactions should be forced. 



Step 2: Query DBA_2PC_P ENDING 



After connecting with SQL*Plus to warehouse, query the local DBA_2PC_PEWriING 
data dictionar}' view to gain information about the in-doubt transaction: 

COHHECT SYSSwarehouse. acme. com A3 SYSDBA 

SELECT ' FROM DRa_2 PC_PEffl}IKG WHERE LOCAL_THAN_ID = '1,31,17'; 

The database returns the following information: 
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Column Name Value 



LOCAL_TRM_ID 1.21.17 

GLOBAL_TRM_ID SALES .ACME. COM.55dlc563. 1 .93 .29 

STATE prepared 

MIXED no 

ADVICE 

TRAF_COMMENT Sales/Hew Order /Trans_type lOB 

FAIL_TIME 31-MAY-91 

FORCE_TIME 

EETRY_TIME 31-MAY-91 

OS_USER SMILLIAHS 

OS_TERMIHAL TWA139 : 

HOST systeml 

DB_USER SlILLIAI^S 

COMMIT# 

Determining the Giobal Transaction iD 

The global transaction ID is the common transaction ID that is the same on everv node 
for a distributed transaction. It is of the form: 

gloha.l_da.ta.ha.se_n.anie.hhhhhhhh . local _tra.n.sa.ction._id 

where: 

■ global_database_name is the database name of the global coordinator. 

■ hhhhhhhh is the internal database identifier of the global coordinator (in 
hexadecimal). 

■ local_transaction_id is the corresponding local transaction ID assigned on 
the global coordinator 

Note that the last portion of the global transaction ID and the local transaction ID 
match at the global coordinator In the example, vou can tell that warehouse is not the 
global coordinator because these numbers do not match: 

LOCAL_TRAN_ID 1.21.17 

GLOBAL_TRAF_ID ... 1.93.29 

Determining the State of the Transaction 

The transaction on this node is in a prepared state: 

STATE prepared 

Therefore, warehouse waits for its coordinator to send either a commit or a rollback 
request 

Loolting for Comments or Advice 

The transaction comment or advice can include information about this transaction. If 
so, use this comment to your advantage. In this example, the origin and transaction 
type is in the transaction comment: 

TRAN_COMMENT Sales/Hew Order /Trans_type lOB 

It could also be provided as a transaction name with a SET TRANSACTION . . . NAME 
statement 

This information can reveal something that helps vou decide whether to commit or 
rollback the local portion of the transaction. If useful comments do not accompany an 
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in-doubt transaction, you must complete some extra administrative work to trace the 
session tree and find a node that has resolved the transaction. 

Step 3: Query DBA_2PC_NEIGHB0RS on Local Node 

The purpose of this step is to climb the session tree so that vou find coordinators, 
eventually reaching the global coordinator Along the way, you may find a 
coordinator that has resolved the transaction. If not, you can eventually work your 
way to the commit point site, which will always have resolved the in-doubt 
transaction. To trace the session tree, query the DBA_2PC_NEIGHB0RS view on each 
node. 

In this case, you query this view on the warehouse database: 

COHNECT SYS@warehouse.acme.com AS SYSDBA 
SELECT ' FROM DBA_2PC_NEIGHB0RS 

WHERE LOCAL_TRAM_ID = ■1.21.17' 

ORDER BY SESStt, IH_OUT; 



Column Hame 


Value 


LOCAL TRAH ID 


1.21.17 


IN_OUT 


in 


DATABASE 


SALES.ACME.COM 


DBUSER OWMER 


SlILLIAMS 


IHTERFACE 


H 


DBID 


000003F4 


SESS# 


1 


BRANCH 


0100 



Obtaining Database Role and Database Link information 

The DBA_2PC_NEIGHB0RS view provides information about connections associated 
with an in-doubt transaction. Information for each connection is different, based on 
whether the connection is inbound (IN_0UT = in) or outbound (IN_0UT = out): 



iN_ 


OUT 


Meaning 


DATABASE 


DBUSER.OWNER 


in 




Your node is a server 


Lists the name of the 


Lists the local account for 






of another node. 


client database that 
connected to your node. 


the database link 
connection that 
corresponds to the 
in-doubt transaction. 


oul 




Your node is a client of 


Lists the name of the 


Lists the owner of the 






other servers. 


database link that 
connects to the remote 
node. 


database link for the 
in-doubt transaction. 



In this example, the IN_OUT column reveals that the warehouse database is a server 
for the sales client, as specified in the DATABASE column: 



IN_OUT 
DATABASE 



in 
SALES.ACME.COM 



The connection to warehouse was established through a database link from the 
swilliams account, as shown by the DBUSER_OWNER column: 



DBUSER OWNER 



SWILLIAMS 
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Determining the Commit Point Site 

Additionallv, the INTERFACE column tells whether the local node or a subordinate 
node is the commit point site: 

INTERFACE N 

Neither warehouse nor any of its descendants is the commit point site, as shown by 
the INTERFACE column. 

Step 4: Querying Data Dictionary Views on All Nodes 

At this point, you can contact the administrator at the located nodes and ask each 
person to repeat Steps 2 and 3 using the global transaction ID. 

Note: If you can directly connect to these nodes with another 
network, you can repeat Steps 2 and 3 yourself. 

For example, the following results are returned when Steps 2 and 3 are performed at 

sales and hq. 

Checlting tlie Status of Pending Transactions at saies 

At this stage, the sales administrator queries the DBA_2PC_P ENDING data dictionary 
view: 

SQL> CONMECT 3YS@saleE.acme.com AS SYSDBA 
SQL> 3EI.ECT ' FROM DBA_2PC_PEHDIHG 

> IHEEE GLOBAL_TRAH_ID = 'SALES.ACME.COM. 55dlc563 .1 . 93 . 29 ' ; 

Column Name Value 



LOCAL_TRAM_ID 1.93.29 

GLOBAL_TRAH_ID SALES .ACME.COM. 55dlc563 . 1 .93 .29 

STATE prepared 

MIXED no 

ADVICE 

TRAH_COHMENT Sales/Hew Order/Trans_type lOB 

FAIL TIME 31-MAY-91 



FORCE_TIME 

EETRY_TIME 31-MAY-91 

OS_USER SlILLIAMS 

OS_TERMIHAL TMA139 : 

HOST systeml 

DB_USER SlILLIAMS 

COMMITtt 

Determining tlie Coordinators and Commit Point Site at saies 

Next, the sales administrator queries DBA_2PC_NEIGHB0RS to determine the global 
and local coordinators as well as the commit point site: 

SELECT ' FROM DBA_2PC_NEIGHB0RS 

WHERE GLOBAL_TRAN_ID = ' SALES .ACME.COM. 55dlc563 . 1. 93 .29 ' 
ORDER BY SESS#, IN_OUT; 

This query returns three rows: 

■ The connection to warehouse 
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■ The connection to hq 

■ The connection estabUshed by the user 

Reformatted information corresponding to the rows for the warehouse connection 
appears below: 



Column Hame 


Value 


LOCAL TRM ID 


1.93.29 


IN OUT 


OUT 


DATABASE 


WAREHOUSE . ACME . COM 


DBUSER OWNER 


SWILLIAMS 


INTERFACE 


H 


DBID 


55dlc563 


SE5S# 


1 


BRANCH 


1 



Reformatted information corresponding to the row^s for the hq connection appears 
below: 



Column Name 


Value 


LOCAL_TRAH_ID 


1.93.29 


IN OUT 


OUT 


DATABASE 


HQ.ACME.COM 


DBUSER_OWMER 


ALLEN 


INTERFACE 


C 


DBID 


00000390 


SESS# 


1 


BRANCH 


1 



The information from the previous queries reveal the following: 

■ sales is the global coordinator because the local transaction ID and global 
transaction ID match. 

■ Two outbound connections are established from this node, but no inbound 
connections, sales is not the server of another node. 

■ hq or one of its servers is the commit point site. 

Checking the Status of Pending Transactions at HQ 

At this stage, the hq administrator queries the DBA_2PC_PENDING data dictionary 



SELECT ' FROM DBA_2PC_PENDING@hq.acme.com 

WHERE GLOBAL_TRAH_ID = ' SALES .ACME.COM. 55dlc563 . 1. 93 .29 ' ; 



Column Name 



Value 



LOCAL_TRAN_ID 

GLOBAL_TRAH_ID 

STATE 

MIXED 

ACTIOM 

TRAN_COMMENT 

FAIL_TIME 

FORCE_TIME 

RETRY_TIME 

OS_USER 

OS TERMINAL 



1.45.13 

SALES.ACME.COM.55dlc563.1.93.2 9 
COMMIT 
NO 

Sales/New Order/Trans_type lOB 
31 -MAY- 91 

31 -MAY- 91 
SWILLIAMS 
TWA139: 
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HOST SYSTEMl 

DB_tISER SlILLIMS 

COMMIT* 129314 



At this point, you liave found a node tliat resolved tlie transaction. As tlie view 
reveals, it has been committed and assigned a commit ID number: 



STATE COMMIT 

COMMITtI 129314 



Therefore, you can force the in-doubt transaction to commit at vour local database. It is 
a good idea to contact anv other administrators vou know that could also benefit from 
your investigation. 



Step 5: Commit the In-Doubt Transaction 

You contact the administrator of the sales database, who manually commits the 
in-doubt transaction using the global ID: 

SQL> COtfflECT SYS@Eales.acrae.com AS SYSDBA 

S2L> COMMIT FORCE ' SALES .ACME. COM.55dlc563 .1 .93 . 29 ' ; 

As administrator of the warehouse database, you manually comm.it the in-doubt 
transaction using the global ID: 

SQL> COIfflECT SYS@warehouse.acme.com AS SYSDEA 

S2L> COMMIT FORCE ' SALES .ACME. C0M.55dlc563 . 1 .93 . 29 ' ; 

Step 6: Check for lUlixed Outcome Using DBA_2PC_PENDING 

After vou manually force a transaction to commit or roll back, the corresponding row 
in the pending transaction table remains. The state of the transaction is changed 
depending on how vou forced the transaction. 

Every Oracle Database has a pending transaction table. This is a special table that 
stores information about distributed transactions as thev proceed through the 
two-phase commit phases. You can query the pending transaction table of a database 
through the DBA_ 2 PC_P ENDING data dictionary' view (see Table 33-1), 

Also of particular interest in the pending transaction table is the mixed outcome flag as 
indicated in DBA_2PC_PENDING. MIXED, You can make the wrong choice if a pending 
transaction is forced to commit or roll back. For example, the local administrator rolls 
back the transaction, but the other nodes commit it. Incorrect decisions are detected 
automatically, and the damage flag for the corresponding pending transaction record 

isset (MIXED=Yes), 

The RECO (Recoverer) background process uses the information in the pending 
transaction table to finalize the status of in-doubt transactions. You can also use the 
information in the pending transaction table to manually override the automatic 
recovery procedures for pending distributed transactions. 

All transactions automaticallv resolved by RECO are removed from the pending 
transaction table. Additionally, all information about in-doubt transactions correctly 
resolved bv an administrator (as checked when RECO reestablishes communication) 
are automaticallv removed from the pending transaction table. However, all rows 
resolved bv an administrator that result in a mixed outcome across nodes remain in 
the pending transaction table of all involved nodes until they are manually deleted 

using DBMS_TEANSACTIONS.PURGE_MIXED, 
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Data Access Failures Due to Locks 



When vou issue a SQL statement, the database attempts to lock the resources needed 
to success fiilh' execute the statement. If the requested data is currently held hv 
statements of other uncomm.itted transactions, however, and remains locked for a long 
time, a timeout occurs. 

Consider the following scenarios involving data access failure: 

■ Transaction Timeouts 

■ Locks from In-Doubt Transactions 



Transaction Timeouts 



A DML statement that requires locks on a remote database can be blocked if another 
transaction own locks on the requested data. If these locks continue to block the 
requesting SQL statement, then the following sequence of events occurs: 

1. A timeout occurs. 

2. The database rolls back the statement. 

3. The database returns this error message to the user: 

OEA-02049: time-out: distributed transaction waiting for lock 

Because the transaction did not modify data, no actions are necessary as a result of the 
timeout. Applications should proceed as if a deadlock has been encountered. The user 
who executed the statement can try to reexecute the statement later If the lock 
persists, then the user should contact an administrator to report the problem. 

Locks from In-Doubt Transactions 

A query or DML statement that requires locks on a local database can be blocked 
indefinitely due to the locked resources of an in-doubt distributed transaction. In this 
case, the database issues the following error message: 

ORA-01591: lock held by in-doubt distributed transaction identifier 

In this case, the database roils hack the SQL statement immediately. The user w^ho 
executed the statement can trv to reexecute the statement later If the lock persists, the 
user should contact an administrator to report the problem, iiicUiding the ID of the 
in-doubt distributed transaction. 

The chances of these situations occurring are rare considering the low probability of 
failures during the critical portions of the tivo-phase commit. Even if such a failure 
occurs, and assuming quick reco\'erv from a network or svstem failure, problems are 
automaticallv resolved without manual intervention. Thus, problems usually resolve 
before they can be detected by users or database administrators. 

Simulating Distributed Transaction Failure 

You can force the failure of a distributed transaction for the following reasons: 

■ To observe RECO automatically resolving the local portion of the transaction 

■ To practice manually Tesolving in-doubt distributed transactions and observing 
the results 

This section describes the features a\'ailable and the steps necessarv to perform such 
operations. 
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Forcing a Distributed Transaction to Fail 



You can mclude comments in the COMMENT parameter of the COMMIT statement. To 
intentionally induce a failure during the two-phase commit phases of a distributed 
transaction, include the following comment in the COMMENT parameter: 

COMMIT COMHMT ' 0RA-2PC-CRASH-TEST-JJ ' ; 

where n is one of the following integers: 

n EHect 

1 Crash commit point after collect 

2 Crash non-commit-point site after collect 

3 Crash before prepare (non-commit-point 
site) 

4 Crash after prepare (non-commit-point site) 

5 Crash commit point site before com.m.it 

6 Crash com.m.it point site after commit 

7 Crash no n-com.m it-point site before commit 

8 Crash non-commit-point site after commit 

9 Crash commit point site before forget 

10 Crash non-commit-point site before forget 

For example, the following statement returns the following messages if the local 
commit point strength is greater than the remote commit point strength and both 
nodes are updated: 

COMMIT COMMENT ' ORA-2PC-CRASH-TEST-7 ' ; 

OEA-02054: transaction 1.93.29 in-doubt 
OEA-02059: 0EA_CRASH_TER3T_7 in commit comment 

At this point, the in-doubt distributed transaction appears in the DBA_2PC_PENDING 
view. If enabled, RECO automatically resolves the transaction. 



Disabling and Enabling RECO 



The RECO background process of an Oracle Database instance automatically resolves 
failures involving distributed transactions. At exponentially growing time intervals, 
the RECO background process of a node attempts to recover the local portion of an 
in-doubt distributed transaction, 

RECO can use an existing connection or establish a new connection to other nodes 
involved in the failed transaction. When a connection is established, RECO 
automatically resolves all in-doubt transactions. Rows corresponding to any resolved 
in-doubt transactions are automaticallv removed from the pending transaction table of 
each database. 

You can enable and disable RECO using the ALTER SYSTEM statement with the 
ENABLE/DISABLE DISTRIBUTED RECOVERY options. For example, you can 
temporarily disable RECO to force the failure of a two-phase conamit and manually 
resolve the in-doubt transaction. 

The following statement disables RECO: 
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ALTER SYSTEM DISftBI£ DISTRIBUTED RECOVERY; 

Alternatively, the following statement enables RECO so that in-doubt transactions are 
autoKiatically resolved: 

ALTER SYSTEM ENABLE DISTRIBUTED RECOVERY; 



Note: Single-process instances (for example, a PC running 
MS-DOS) have no separate background processes, and therefore no 
RECO process. Therefore, when a single- pro cess instance that 
participates in a distributed system is started, you must manually 
enable distributed recovery using the preceding statement. 



Managing Read Consistency 



An important restriction exists in the Oracle Database implementation of distributed 
read consistency. The problem arises because each system has its own SCN, which you 
can view as the database internal timestamp. The Oracle Database server uses the SCN 
to decide which version of data is returned from a query. 

The SCNs in a distributed transaction are synchronized at the end of each remote SQL 
statement and at the start and end of each transaction. Between two nodes that have 
heavv traffic and especiallv distributed updates, the synchronization is frequent. 
Nevertheless, no practical way exists to keep SCNs in a distributed system absolutelv 
synchronized: a window always exists in which one node may have an SCN that is 
somewhat in the past with respect to the SCN of another node. 

Because of the SCN gap, vou can execute a quer}' that uses a slightly old snapshot, so 
that the most recent changes to the remote database are not seen. In accordance with 
read consistency, a query can therefore retrieve consistent, but out-of-date data. Note 
that all data retrie\'ed b\' the query will be from the old SCN, so that if a locally 
executed update transaction updates two tables at a remote node, then data selected 
from both tables in the next remote access contain data prior to the update. 

One consequence of the SCN gap is that two consecutive SELECT statements can 
retrieve different data even though no DML has been executed between the two 
statements. For example, you can issue an update statement and then commit the 
update on the remote database. When you issue a SELECT statement on a view based 
on this remote table, the view does not show the update to the row. The next time that 
you issue the SELECT statement, the update is present. 

You can use the following techniques to ensure that the SCNs of the two machines are 
synchronized just before a query: 

■ Because SCNs are synchronized at the end of a remote query, precede each remote 
query with a dummy remote query to the same site, for example, SELECT * 

FROM DUALSREMOTE. 

■ Because SCNs are synchronized at the start of even' remote transaction, commit or 
roll back the current transaction before issuing the remote query. 
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Appendices 



This part contains Appendices for the Oracle Database Administrator's Guide, It 
contains tlie following sections: 

■ Appendix A, "Support for DBMSJOB in Release 11 g" 



Support for DBMS_JOB in Release 11 g 



In this appendix: 

. About DBMSJOB 

. Configuring DBMSJOB 

. Using Both DBMSJOB and Oracle Scheduler 

■ Moving from DBMSJOB to Oracle Scheduler 



About DBMS JOB 



DBMS_JOB is a PL /SQL package that vou use to schedule jobs. It is replaced bv Oracle 
Scheduler, which is more powerful and flexible. Although Oracle recommends that 
you switch from DBMS_JOB to Oracle Scheduler, DBMS_JOB is stili supported for 
backward compatibilit}'. 

See Also: Chapter 27, "Scheduling Jobs with Oracle Scheduler" 



Configuring DBIVJS.JOB 

The J0B_QUEUE_PR0CE33E3 initialization parameter specifies the maximum number 
of processes that can be created for the execution of jobs. Beginning with Oracle 
Database release llg, JOB_QUEUE_PROCESSES defaults to 1000. The job coordinator 
process starts onlv as many job queue processes as are required, based on the number 
of jobs to run and available resources. You can set JOB_QUEUE_PROCESgES to a lower 
number to limit the number of job queue processes. Setting JOB_QUEUE_PROCESSES 
to disables DBMS_JOB. 

Using Both DBI\/IS_JOB and Oracle Scheduler 

DBMS_JOB and Oracle Scheduler (the Scheduler) use the same job coordinator to start 
job queue processes. (For the Scheduler, these processes are called job slave processes. 
This section uses these terms interchangeablv.) Although vou typically use the JOB_ 
QUEUE_PROCESSES initialization parameter to limit the number job queue processes 
for DBMS_JOB and you use the Scheduler attribute max_job_slave_proce3 3e3 to 
hmit the number of job slave processes for the Scheduler, the Scheduler is affected by 
the J0B_QUEUE_PROCESSES parameter. 

The maximum number of job slave processes for Scheduler is determined by the lesser 

of the values of JOB_QUEUE_PROCESSES andmax_job_Hlave_processes. For 
example: 
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■ If JOB_QUEUE_PROCESSES is set to 10 .ind max_ j ob_E lave_proceE ses is set 
to 20, tiie job coordinator will start no more than 10 job slave processes to be 
shared between DBMS_JOB and the Scheduler. 

■ If JOB_QUEUE_PROCESSES is 20 and max_ j ob_E lave_proces ses is 10, the 
coordinator will start up to 20 job slave processes. The Scheduler can use only 10 
of these, but DBMS_JOB can use all 20. 

If JOB_QUEUE_PROCESSES is 0, DBMS_JOB is disabled, and the maximum number of 
job slave processes for Scheduler is controlled by theirLax_job_3lave_proce3 3e3 
Scheduler attribute. 

See Also: 

■ "Task 2E: Setting Scheduler Attributes" on page 28-5 

■ Oracle Database Reference for more information about the JOB_ 

QUEUE_PROCESSES initialization parameter 

Moving from DBMS_JOB to Oracle Scheduler 

This section illustrates some examples of how you can take jobs created with the 
DBMS_JOB package and rewrite them using Oracle Scheduler, which you configure 
and control with the DBMS_SCHEDULER package. 

Creating a Job 

An example of creating a job using DBMS_JOB is the following: 

VMIflBLE jobno NUMBER; 

BEGIH 

DBMS_JOB.SDBMIT(:jobiio, 'INSERT INTO einployees VALUES (7935, ''SALLY'', 

''DOGM'', ' 'sally. dogan@?^zcorp. com' ', NULL, SYSDATE, ''AD_PRES'', NULL, 
NULL, [TOLL, HULL);', SYSDATE, ' SYSDATE+ 1 ' ) ; 
COMMIT; 
END; 
/ 

An equivalent statement using DBMS_SCHEDULER is the following: 

BEGIH 
DBMS_SCHEDULER.CEEATE_JOB( 

job_naine => 'jobl', 

job_type => 'PLSQL_BLOCK' , 

job_action => ' IHSERT INTO employees VALUES (7935, ''SALLY", 

''DOGAN'', ' 'sally. doganSxyzcorp. com' ' . NULL, SYSDATE, ' 'flD_PRES '' , HULL, 
NULL, HULL, NULL) ; ') ; 

start_date => SYSDATE, 

repeat_interval => 'FEEQ = DAILY; INTERVAL =1'); 
END; 
/ 



Altering a Job 



An example of altering a job using DBMS_JOB is the following: 

BEGIH 

DBMS_J0B.1HAT(31, 'IHSERT IHTO employees VALUES (7935, ''TOM'', ''DOGAN' 

''tom.dogan@xyzcorp.com'', NULL, SYSDATE, ' 'AD_PRES '' , HULL, 

HULL, HULL, NULL) ; ') ; 
COMMIT; 
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EKD; 

/ 

This changes the action for JOBl to insert a different value. An equivalent statement 
using DBMS_SCHEDULEE is the following: 

BEGIN 

DfflS_SCHEDUtER . SETJTTRIBUTE ( 
name => 'JOBl ' , 
attribute => ' job_action' , 

value => 'INSERT INTO employees VALUES {7935, ' 'TOM' ' , ' 'DOGM' ' , 
''tom.dogan@xyzcorp.com'', NULL, SYSDATE, ''AD_PHES'', NULL, 
NULL, HULL, NULL) ; ' ) ; 
END; 
/ 

Removing a Job from the Job Queue 

The following example removes a job using DBMS_JOB, where 14144 is the number of 
the job being run: 

BEGIN 

DBMS_J0B.HEH0VE(14144) ; 

COMMIT; 

END; 

/ 

Using DBMS_SCHEDULER, you would issue the following statement instead: 
BEGIN 

DBMS_SCHEDULER.DROP_JOB( 'myjobl' ) ; 
END; 
/ 

See Also: 



Orack' Database PL/SQL Packages and Types Reference for more 
information about the DBMS_SCHEDULER package 

Chapter 27, "Scheduling Jobs with Oracle Scheduler" 
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CLEAR UNARCHIVED LOGFILE clause, 10-5 

database partially available to users, 3-7 

DATAFILE. .OFFLINE DROP clause, 13-7 

datafiles online or offline, 13-8 

DROP LOGFILE clause, 10-12 

DROP LOGFILE MEMBER clause, 10-13 

MOUNT clause, 3-7 

NOARCHIVELOG clause, 11-4 

OPEN clause, 3-7 

READ ONLY clause, 3-8 

RENAME FILE clause, 13-10 

tempfiles online or offline, 13-8 

UNRECOVERABLE DATAFILE clause, 10-14 
ALTER INDEX statement 

COALESCE clause, 19-6 

MONITORING USAGE clause, 19-14 
ALTER SEQUENCE statement, 22-13 
ALTER SESSION 

Enabling resumable space allocation, 17-11 
ALTER SESSION statement 

ADVISE clause, 33-7 

CLOSE DATABASE LINK clause, 31-2 

SET SQL_TRACE initialization parameter, 7-3 

setting time zone, 2-21 
ALTER SYSTEM statement 

ARCHIVE LOG ALL clause, 11-5 

DISABLE DISTRIBUTED RECOVERY 
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ckuse, 33-18 

ENABLE DISTRIBUTED RECOVERY 
ckuse, 33-18 

ENABLE RESTRICTED SESSION clause, 3-8 

enabling Database Resource Manager, 25-30 

QUIESCE RESTRICTED, 3-12 

RESUME clause, 3-13 

SCOPE clause for SET, 2-36 

SET RESOURCE_MANAGER_PLAN, 25-30 

SET SHARED_SERVERS initialization 
parameter, 4-8 

setting initialization parameters, 2-36 

SUSPEND clause, 3-13 

SWITCH LOGFILE clause, 10-13 

UNQUIESCE, 3-13 
ALTER TABLE ADD COLUMN command, xxxiii 
ALTER TABLE statement 

ADD (column) clause, 18-23 

ALLOCATE EXTENT clause, 18-22 

DEALLOCATE UNUSED clause, 18-22 

DISABLE ALL TRIGGERS clause, 16-9 

DISABLE integrity constraint clause, 16-12 

DROP COLUMN'clause, 18-24 

DROP integrity constraint clause, 16-13 

DROP UNUSED COLUMNS clause, 18-24 

ENABLE ALL TRIGGERS clause, 16-9 

ENABLE integrity constraint clause, 16-12, 16-13 

external tables, 18-62 

MODIFY (column) clause, 18-22 

modifying index-organized table attributes, 18-55 

MOVE clause, 18-21, 18-22, 18-55 

reasons for use, 18-20 

RENAME COLUMN clause, 18-23 

SET UNUSED clause, 18-24 
ALTER TABLESPACE statement 

adding an Oracle-managed datafile, 
example, 15-13 

adding an Oracle-managed tempfile, 
example, 15-14 

ONLINE clause, example, 12-17 

READ ONLY clause, 12-17 

READ WRITE clause, 12-19 

RENAME DATAFILE clause, 13-9 

RENAMETO clause, 12-23 

taking datafiles/tempfiles online/offline, 13-8 
ALTER TRIGGER statement 

DISABLE clause, 16-9 

ENABLE clause, 16-8 
altering 

(Scheduler) windows, 27-25 

chain steps, 27-46 

event schedule, 27-38 

event-based job, 27-38 

job classes, 27-22 

jobs, 27-8 

programs, 27-14 

schedules, 27-16 
altering indexes, 19-12, 19-13 
ANALYZE statement 

CASCADE clause, 16-3 



CASCADE clause, FAST option, 16-3 

corruption reporting, 23-3 

listing chained rows, 16-4 

remote tables, 31-5 

validating structure, 16-3, 23-3 
analyzing schema objects, 16-2 
analyzing tables 

distributed processing, 31-5 
application development 

distributed databases, 29-31, 31-1, 31-9 
application development for distributed 
databases, 31-1 

analyzing execution plan, 31-7 

database links, controlling connections, 31-1 

handling errors, 31-2, 31-8 

handling remote procedure errors, 31-8 

managing distribution of data, 31-1 

managing referential integrity constraints, 31-2 

terminating remote connections, 31-2 

tuning distributed queries, 31-2 

tuning using collocated inline views, 31-3 

using cost-based optimization, 31-3 

using hints to tune queries, 31-6 
application services 

configuring, 2-42 

defining, 2-40 

deploying, 2-41 

using, 2-42 

using, client side, 2-43 

using, server side, 2-43 
ARCHIVE_LAG_TARGET initialization 

parameter, 10-8 
archived redo logs 

archiving modes, 11-4 

data dictionary views, 11-14 

destination availability state, controlling, 11-9 

destination status, 11-8 

destinations, specifj'ing, 11-6 

failed destinations and, 11-11 

mandatory destinations, 11-11 

minimum number of destinations, 11-11 

multiplexing, 11-6 

normal transmission of, 11-9 

re-archiving to failed destination, 11-13 

sample destination scenarios, 11-12 

standby transmission of, 11-9 

status information, 11-15 

transmitting, 11-9 
ARCHIVELOG mode, 11-3 

advantages, 11-3 

archiving, 11-2 

automatic archiving in, 11-3 

definition of, 11-3 

distributed databases, 11-3 

enabling, 11-4 

manual archiving in, 11-3 

running in, 11-3 

switching to, 11-4 

taking datafiles offline and online in, 13-7 
archiver process 
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trace output (controlling), 11-13 
archiver process (ARCn), 4-19 
archiving 

changing archiving mode, 11-4 

controlling number of processes, 11-5 

destination availability state, controlling, 11-9 

destination failure, 11-11 

destination status, 11-8 

manual, 11-5 

NOARCHIVELOG vs. ARCHIVELOG 
mode, 11-2 

setting initial mode, 11-4 

to failed destinations, 11-13 

trace output, controlling, 11-13 

viewing information on, 11-15 
auditing 

database links, 20-21 
authentication 

database links, 29-17 

operating system, 1-18 

selecting a method, 1-16 

using password file, 1-19 
AUTO_TASK_CONSUMER_GROUP 

of Resource Manager, 24-5 
AUTOEXTEND clause 

for bigfile tablespaces, 12-21 
automatic diagnostic repository, 8-1, 8-4 

structure, contents and location of, 8-6 
Automatic Maintenance Tasks 

assigning to maintenance windows, 24-4 

definition, 24-1 

enabling and disabling, 24-3 

predefined, 24-2 

resource allocation, 24-5 
Automatic maintenance tasks 

Scheduler job names, 24-2 
automatic memory management, 5-1 

about, 5-3 

enabling, 5-4 

supported platforms, 5-21 
automatic segment space management, 12-5 
Automatic Storage Management 

initialization files and, 3-3 
automatic undo management, 2-17, 14-2 

migrating to, 14-11 

B 

background processes, 4-18 

FMON, 13-17 
BACKGROUND_DUMP_DEST initialization 

parameter, 8-5 
backups 

after creating new databases, 2-14 

effects of archiving on, 1 1-2 
batch jobs, authenticating users in, 2-44 
bigfile tablespaces 

creating, 12-7 

creating temporary, 12-12 

description, 12-6 



setting database default, 2-20 
BLANK.TRIMMING initialization parameter, 18-23 
BLOB datatype, 18-9 
BLOCKSIZE clause 

of CREATE TABLES? ACE, 12-14 
buffer caches 

extended buffer cache (32-bit), 5-19 

multiple buffer pools, 5-16 
buffer pools, 5-16 
BUFFER_POOL parameter 

description, 17-6 
BlJFFER_POOL_KEEP initialization parameter, 5-16 
BUFFER _POOL_RECYCLE initialization 

parameter, 5-16 
buffers 

buffer cache in SGA, 5-15 



CACHE option 

CREATE SEQUENCE statement, 22-16 
caches 

buffer 

multiple buffer pools, 5-16 

sequence numbers, 22-15 
calendaring expressions, 27-17 
calls 

remote procedure, 29-33 
capacity planning 

space management 

capacity planning, 17-35 
CASCADE clause 

when dropping unique or primary keys, 16-13 
CATBLOCK.SQL script, 7-7 
centralized user management 

distributed systems, 29-19 
chain rules, 27-42 
chain steps 

defining, 27-41 
chained rows 

eliminating from table, procedure, 16-4 
CHAlNED_ROWS table 

used by ANALYZE statement, 16-4 
chains 

creating, 27-41 

creating jobs for, 27-44 

disabling, 27-45 

dropping, 27-44 

dropping rules from, 27-45 

enabling, 27-43 

monitoring, 28-12 

overview, 26-7 

running, 27-45 

setting privileges, 28-2 

stalled, 27-47 

using, 27-40 
change vectors, 10-2 
CHAR datatype 

increasing column length, 18-22 
character set 
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choosing, 2-3 
CHECK_OBJECT procedure 

DBMS_REPAIR package, 23-2 

example, 23-7 

finding extent of corruption, 23-4 
checkpoint process (CKPT), 4-19 
checksums 

for datii blocks, 13-12 

redo log blocks, 10-13 
CLEAR LOGHLE clause 

ALTER DATABASE statement, 10-14 
clearing redo log files, 10-5, 10-14 
client/server architectures 

distributed databases, 29-4 

globalization support, 29-34 
cloning 

a datiibase, 1-6 

an Oracle home, 1-6 
CLOSE DATABASE LINK clause 

ALTER SESSION statement, 31-2 
closing database links, 30-14 
closing windows, 27-26 
clusters 

about, 20-1 

allocating extents, 20-6 

altering, 20-6 

analyzing, 16-2 

cluster indexes, 20-7 

cluster keys, 20-1, 20-3, 20-4 

clustered tables, 20-1, 20-3, 20-5, 20-6, 20- 

columns for cluster key, 20-3 

creating, 20-4 

data dictionary views reference, 20-8 

deallocating extents, 20-6 

dropping, 20-7 

estimating space, 20-3, 20-4 

guidelines for managing, 20-2, 20-4 

hash clusters, 21-1 

location, 20-4 

privileges, 20-4, 20-6, 20-8 

selecting tables, 20-3 

single-table hash clusters, 21-4 

sorted hash, 21-3 

truncating, 16-6 

validating structure, 16-3 
coalescing indexes 

costs, 19-5 
collocated inline views 

tuning distributed queries, 31-3 
column encryption, 2-44 
columns 

adding, 18-23 

adding to compressed table, 18-23 

displaying information about, 18-65 

dropping, 18-24, 18-25 

dropping in compressed tables, 18-25 

encrypted, 18-6, 18-21 

increasing length, 18-22 

modifj'ing definition, 18-22 

renaming, 18-23 



virtual, 18-2 

virtual, indexing, 19-3 
commands 

submitting, 1-6 
COMMENT statement, 18-64 
comments 

adding to problem activity log, 8-14 
COMMIT COMMENT statement 

used with distributed transactions, 33-2, 33-7 
commit phase, 32-8, 32-17 

in two-phase commit, 32-10, 32-11 
commit point site, 32-5 

commit point strength, 32-6, 33-1 

determining, 32-6 

distributed transactions, 32-5, 32-6 

how the database determines, 32-6 
commit point strength 

definition, 32-6 

specifying, 33-1 
COMMIT statement 

FORCE clause, 33-8, 33-9 

forcing, 33-6 

two-phase commit and, 29-25 
COMMIT_POINT_STRENGTH initialization 

parameter, 32-6, 33-1 
committing transactions 

commit point site for distributed 
transactions, 32-5 
compressed tables 

adding a column, 18-23 

dropping columns in, 18-25 
compression, table, 18-5 
configuring 

Oracle Scheduler, 28-1 
CONNECT command 

starting an instance, 3-4 
CONNECT INTERNAL 

desupported, 1-17 
connected user database links, 30-9 

advantages and disadvantages, 29-12 

definition, 29-11 

example, 29-13 

REMOTE_OS_ALITHENT initialization 
parameter, 29-12 
connecting 

with SQL 'Plus, 1-7 
connection qualifiers 

database links and, 30-10 
connections 

terminating remote, 31-2 
constraints 

See also integrity constraints 

disabling at table creation, 16-11 

distributed system application development 
issues, 31-2 

dropping integrity constraints, 16-13 

enable novalidate state, 16-11 

enabling example, 16-12 

enabling when violations exist, 16-11 

exceptions, 16-10, 16-14 
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exceptions to integrity constraints, 16-14 

integrity constraint states, 16-10 

keeping index when disabling, 16-12 

keeping index when dropping, 16-12 

ORA-02055 constraint violation, 31-2 

renaming, 16-13 

setting at table creation, 16-11 

when to disable, 16-10 
control files 

adding, 9- A 

changing size, 9-3 

conflicts with data dictionary, 9-7 

creating, 9-1,9-3,0-5 

creating as Oracle-managed files, 15-14 

creating as Oracle-managed files, examples, 15-20 

data dictionary views reference, 9-9 

default name, 2-26, 9-3 

dropping, 9-9 

errors during creation, 9-7 

guidelines for, 9-2 

importance of multiplexed, 9-2 

initial creation, 9-3 

location of, 9-3 

log sequence numbers, 10-3 

mirroring, 2-27, 9-2 

moving, 9-4 

multiplexed, 9-2 

names, 9-2 

number of, 9-2 

overwriting existing, 2-26 

relocating, 9-4 

renaming, 9-4 

requirement of one, 9-1 

size of, 9-3 

specifying names before database creation, 2-26 

troubleshooting, 9-7 

unavailable during startup, 3-5 
CONTROL_HLES initialization parameter 

overwriting existing control files, 2-26 

specifying file names, 9-2 

when creating a database, 2-26, 9-3 
CONTROLFILE REUSE clause, 2-27 
copying jobs, 27-7 
coraenv and oraenv, 1-8 
core files, 8-5 
corruption 

repairing data block, 23-1 
cost-based optimization, 31-3 

distributed databases, 29-33 

hints, 31-6 

using for distributed queries, 31-3 
CREATE BIGFILE TABLESPACE statement, 12-7 
CREATE BIGHLE TEMPORARY TABLESPACE 

statement, 12-12 
CREATE CLUSTER statement 

creating clusters, 20-5 

example, 20-5 

for hash clusters, 21-2 

HASH IS clause, 21-3,21-5 

HASHKEYS clause, 21-3, 21-6 



SlZEclause, 21-5 

CREATE CONTROLFILE statement 

about, 9-5 

checking for inconsistencies, 9-7 

creating as Oracle-managed files, 
examples, 15-15, 15-20 

NORESETLOGS clause, 9-6 

Oracle-managed files, using, 15-14 

RESETLOGS clause, 9-6 
CREATE DATABASE LINK statement, 30-7 
CREATE DATABASE statement 

CONTROLFILE REUSE clause, 9-3 

DEFAULT TEMPORARY TABLESPACE 
clause, 2-11,2-18 

example of database creation, 2-9 

EXTENT MANAGEMENT LOCAL clause, 2-15 

MAXLOGFILES parameter, 10-7 

MAXLOGMEMBERS parameter, 10-7 

password for SYS, 2-15 

password for SYSTEM, 2-15 

setting time zone, 2-21 

specifying FORCE LOGGING, 2-22 

SYSAUX DATAFILE clause, 2-11 

UNDO TABLESPACE clause, 2-11, 2-17 

used to create an undo tablespace, 14-8 

using Oracle-managed files, 15-7 

using Oracle-managed files, examples, 15-10, 
15-18, 15-22 
CREATE INDEX statement 

NOLOGGING, 19-5 

ON CLUSTER clause, 20-6 

using, 19-7 

with a constraint, 19-8 
CREATE PFILE FROM MEMORY command, 2-38 
CREATE SCHEMA statement 

multiple tables and views, 16-1 
CREATE SEQUENCE statement, 22-13 

CACHE option, 22-16 

examples, 22-16 

NOCACHE option, 22-16 
CREATE SPFILE statement, 2-32 
CREATESYNONYM statement, 22-17 
CREATE TABLE statement 

AS SELECT clause, 18-4, 18-11 

AS SELECT vs. direct-path INSERT, 18-16 

CLUSTER clause, 20-5 

COMPRESS clause, 18-54 

creating temporary table, 18-9 

example of, 18-8 

INCLUDING clause, 18-52 

index-organized tables, 18-50 

MONITORING clause, 18-19 

NOLOGGING clause, 18-4 

ORGANIZATION EXTERNAL clause, 18-59 

parallelizing, 18-11 

PCTTHRESHOLD clause, 18-52 

TABLESPACE clause, specifj'ing, 18-3 
CREATE TABLESPACE statement 

BLOCKSIZE CLAUSE, using, 12-14 

FORCE LOGGING clause, using, 12-14 
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using Oracle -managed files, 15-11 

using Oracle-managed files, examples, 15-12 
CREATE TEMPORARY TABLES? ACE 
statement, 12-11 

using Oracle-managed tiles, 15-13 

using Oracle-managed files, example, 15-14 
CREATE UNDO TABLES? ACE statement 

using Oracle-managed tiles, 15-11 

using Oracle-Managed files, example, 15-13 

using to create an undo tablespace, 14-8 
CREATE UNIQUE INDEX statement 

using, 19-7 
CREATE VIEW statement 

about, 22-2 

OR REPLACE clause, 22-4 

WITH CHECK OPTION, 22-2, 22-5 
CREATE_SIMPLE_PLAN procedure 

Database Resource Manager, 25-9 
creating 

chains, 27-41 

control files, 9-3 

event schedule, 27-38 

event-based job, 27-37 

indexes, 19-6 

after inserting table data, 19-2 

associated with integrity constraints, 19-8 

NOLOGGING, 19-5 

online, 19-9 

USING INDEX clause, 19-8 

job classes, 27-22 

jobs, 27-2 

programs, 27-12 

Scheduler windows, 27-23 

schedules, 27-16 

sequences, 22-16 

window groups, 27-30 
creating a database, 2-2 
creating database links, 30-6 

connected user, 30-9 

connected user scenarios, 30-25 

current user, 30-9 

current user scenario, 30-26 

examples, 29-13 

fixed user, 30-8 

fixed user scenario, 30-25 

obtaining necessary privileges, 30-6 

private, 30-7 

pubhc, 30-7 

service nam.es within link names, 30-10 

shared, 30-10 

shared connected user scenario, 30-26 

specifying types, 30-7 
creating databases, 2-1 

backing up the new database, 2-14 

default temporary tablespace, specifying, 2-18 

example, 2-9 

manually from a script, 2-2 

overriding default tablespace type, 2-21 

planning, 2-2 

preparing to, 2-2 



prerequisites for, 2-4 
problems encountered while, 2-30 
setting default tablespace type, 2-20 
specifying bigfile tablespaces, 2-20, 2-21 
UNDO TABLESPACE clause, 2-17 
upgrading to a new release, 2-2 
using Oracle-managed files, 2-18, 15-7 
with locally managed tablespaces, 2-15 

creating datafiles, 13-4 

creating sequences, 22-13 

creating synonyms, 22-17 

creating views, 22-2 

credentials 

creating, 26-11 

granting privileges on, 26-11 

credentials, for remote external jobs, 26-11 

critical errors 

diagnosing, 8-1 

current user database links 

advantages and disadvantages, 29-12 

cannot access in shared schema, 29-20 

definition, 29-11 

example, 29-13 

schema independence, 29-19 

CURRVAL pseudo-column, 22-14 
restrictions, 22-15 

cursors 

and closing database links, 31-2 

customize package page, accessing, 8-37 

customizing an incident package, 8-36, 8-37 



data 

loading using external tables, 18-60 
data block corruption 

repairing, 23-1 
data blocks 

altering size of, 2-27 

managing space in, 17-4 

nonstandard block size, 2-28 

shared in clusters, 20-1 

specifying size of, 2-27 

standard block size, 2-27 

transaction entry settings, 17-4 

verifying, 13-12 
data dictionary 

conflicts with control files, 9-7 

purging pending rows from, 33-9, 33-10 

See also views, data dictionary 
data encryption 

distributed systems, 29-21 
data manipulation language 

statements allowed in distributed 
transactions, 29-23 
Data Recovery Advisor, repairing data corruptions 

with, 8-28 
Data Repair Advisor, 8-2 
database 

cloning, 1-6 
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creating, 2-2 

data dictionary views reference, 2-45 

starting up, 3-1 
databaseadministrators 

DBA role, 1-14 

operating system account, 1-13 

password files for, 1-17 

responsibilities of, 1-1 

security and privileges of, 1-13 

security officer versus, 6-1 

SYS and SYSTEM accounts, 1-13 

task definitions, 1-3 

utilities for, 1-25 
database buffers 

multiple buffer pools, 5-16 
Database Configuration Assistant, 2-2 

shared server configuration, 4-10 
database links 

advantages, 29-8 

auditing, 29-21 

authentication, 29-17 

authentication without passwords, 29-18 

closing, 30-14,31-2 

connected user, 29-11, 29-12, 30-9, 30-25 

connections, determining open, 30-17 

controlling connections, 31-1 

creating, 30-6, 30-25, 30-26 

creating shared, 30-12 

creating, examples, 29-13 

creating, scenarios, 30-24 

current user, 29-11, 29-12, 30-9 

data dictionary USER views, 30-16 

definition, 29-6 

distributed queries, 29-24 

distributed transactions, 29-25 

dropping, 30-15 

enforcing global naming, 30-2 

enterprise users and, 29-19 

fixed user, 29-11, 29-12, 30-25 

global, 29-10 

global names, 29-8 

global object names, 29-25 

handling errors, 31-2 

limiting number of connections, 30-16 

listing, 30-16,33-2,33-4 

managing, 30-14 

minimizing network connections, 30-11 

name resolution, 29-25 

names for, 29-9 

private, 29-10 

pubhc, 29-10 

referential integrity in, 31-2 

remote transactions, 29-23, 29-24 

resolution, 29-25 

restrictions, 29-16 

roles on remote database, 29-16 

schema objects and, 29-14 

service names used within link names, 30-10 

shared, 29-7, 30-11, 30-12, 30-13 

shared SQL, 29-24 



synonyms for schema objects, 29-15 

tuning distributed queries, 31-2 

tuning queries with hints, 31-6 

tuning using collocated inline views, 31-3 

types of links, 29-10 

types of users, 29-11 

users, specifj'ing, 30-8 

using cost-based optimization, 31-3 

viewing, 30-16 
database objects 

obtaining growth trends for, 17-36 
database resident connection pooling, 4-4 

advantages, 4-4 

configuration parameters, 4-16 

configuring the connection pool, 4-16 

data dictionary views reference, 4-18 

disabling, 4-16 

enabling, 4-15 

restrictions, 4-6 
Database Resource Manager 

active session pool with queuing, 25-7 

administering system privilege, 25-8 

and operating system control, 25-41 

automatic consumer group switching, 25-8 

CEEATE_SIMPLE_PLAN procedure, 25-9 

data dictionary views reference, 25-45 

description, 25-1 

enabling, 25-30 

execution time limit, 25-8 

resource allocation methods, 25-12, 25-13 

resource consumer groups, 25-3, 25-12, 25-20 

resource plan directives, 25-3, 25-14, 25-18 

resource plans, 25-3, 25-6, 25-7, 25-9, 25-30, 25-31, 
25-34 

undo pool, 25-8 

used for quiescing a database, 3-11 

validating plan schema changes, 25-18 
database writer process 

calculating checksums for data blocks, 13-12 
database writer process (DBWn), 4-19 
DATABASE.PROPERTIES view 

rename of default temporary tabiespace, 12-24 
d atab ases 

administering, 1-1 

administration of distributed, 30-1 

altering availability, 3-7 

backing up, 2-14 

control files of, 9-2 

default temporary tabiespace, specifying, 2-18 

dropping, 2-30 

global database names in distributed 
systems, 2-26 

mounting a database, 3-5 

mounting to an instance, 3-7 

names, about, 2-26 

names, conflicts in, 2-26 

opening a closed database, 3-7 

planning, 1-4 

planning creation, 2-2 

quiescing, 3-11 
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read-only, opening, 3-8 

recovery, 3-7 

renaming, 9-4, 9-5, 9-5 

restricting access, 3-8 

resuming, 3-13 

shutting down, 3-8 

specifying control files, 2-26 

starting up, 3-2 

suspending, 3-13 

troubleshooting creation problems, 2-30 

undo management, 2-17 

upgrading, 2-2 

with locally managed tablespaces, 2-15 
datatile headers 

when renaming tablespaces, 12-23 
datafiles 

adding to a tablespace, 13-4 

bringing onhne and offline, 13-6 

checking associated tablespaces, 12-46 

copying using database, 13-12 

creating, 13-4 

creating Oracle-managed files, 15-5, 15-17 

data dictionary views reference, 13-25 

database administrators access, 1-13 

default directory, 13-5 

definition, 13-1 

deleting, 12-24 

dropping, 13-7, 13-11 

dropping Oracle-managed files, 15-17 

file numbers, 13-1 

fully specifying filenames, 13-5 

guidelines for managing, 13-1 

headers when renaming tablespaces, 12-23 

identifying OS filenames, 13-10 

location, 13-4 

mapping files to physical devices, 13-15 

minimum number of, 13-2 

MISSING, 9-7 

online, 13-7 

Oracle-managed, 15-1 

relocating, 13-8 

renaming, 13-8 

reusing, 13-5 

size of, 13-3 

statements to create, 13-4 

storing separately from redo log files, 13-4 

unavailable when database is opened, 3-5 

verifying data blocks, 13-12 
DB_Bl6cK_CHECKING initialization 

parameter, 23-3, 23-4 
DB_BLOCK_CHECKSUM initialization 
parameter, 13-12 

enabling redo block checking with, 10-13 
DB_BLOCK_SIZE initialization parameter, 5-15 

and nonstandard block sizes, 12-14 

setting, 2-27 
DB_CACHE_SIZE initialization parameter, 5-16 

specifying multiple block sizes, 12-14 
DB_CREATE_FILE_DEST initialization 
parameter, 15-4 



setting, 15-4 
DB_CREATE_ONLINE_LOG_DEST_n initialization 
parameter, 15-4 

setting, 15-5 
DB_DOMAIN initialization parameter 

setting for database creation, 2-25, 2-26 
DB_FILES initialization parameter 

determining value for, 13-2 
DB_KEEP_CACHE_SIZE initiahzation 

parameter, 5-16 
DB_NAME initialization parameter 

setting before database creation, 2-25 
DB_nK_CACHE_SIZE initialization parameter, 5-16 

specifying multiple block sizes, 12-14 

using with transportable tablespaces, 12-41 
DB_RECO VERY _HLE_DEST initialization 
parameter, 15-4 

setting, 15-5 
DB_EECYCLY_CACHE_S1ZE initialization 

parameter, 5-16 
DBA role, 1-14 

DBA. See database administrators. 
DBA_2PC_NEIGHBORS view, 33-4 

using to trace session tree, 33-4 
DBA_2PC_PENDING view, 33-2, 33-9, 33-16 

using to list in-doubt transactions, 33-2 
DBA_DB_LINKS view, 30-16 
DBA_RESUMABLE view, 17-12 
DBA_UNDO_EXTENTS view 

undo tablespace extents, 14-12 
DBCA. Sec Database Configuration Assistant 
DBMS_F1LE_TRANSFER package 

copying datafiles, 13-12 
DBMS JOB 

about, A-1 

m.ovingjobs to Oracle Scheduler, A-2 
DBMS_METADATA package 

GET_DDL function, 16-21 

using for object definition, 16-21 
DBMS_REDEFINITION package 

performing online redefinition with, 18-28 

required privileges, 18-42 
DBMS_REPAIR 

logical corruptions, 23-4 
DBMS_REPAIR package 

examples, 23-5 

limitations, 23-2 

procedures, 23-2 

using, 23-2,23-10 
DBMS_RESOURCE_MANAGER package, 25-3, 
25-9, 25-21 

procedures (table of), 25-8 
DBMS_RESOURCE_MANAGER_PRIVS 
package, 25-9 

procedures (table of), 25-8 
DBMS_RESUMABLE package, 17-13 
DBMS_SERVER_ALERT package 

setting alert thresholds, 17-2 
DBMS_SPACE package, 17-30 

example for unused space, 17-32 
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FEEE_BLOCK procedure, 17-31 

SPACE_USAGE procedure, 17-31 

UNUSED .SPACE procedure, 17-31 
DBMS_STATS package, 16-3 

MONITORING clause of CREATE TABLE, 18-10 
DBMS_STORAGE_MAP package 

invoking for file mapping, 13-21 

views detailing mapping information, 13-22 
DBMS_TRANSACTION package 

PURGE_LOST_DB_ENTRY procedure, 33-10 
DBVERIFY utility, 23-3 
DDL lock timeout, 2-28 
DDL_LOCK_TIMEOUT initialization 

parameter, 2-28 
DEALLOCATE UNUSED clause, 17-31 
deallocating unused space, 17-15 

DBMS_SPACE package, 17-30 

DEALLOCATE UNUSED clause, 17-31 
declarative referential integrity constraints, 31-2 
dedicated server processes, 4-1 

trace files for, 7-1 
default temporary tablespace 

renaming, 12-24 
default temporary tablespaces 

specifying at database creation, 2-11, 2-18 

specifying bigtile tempfile, 2-21 
DEFAULT_CONSUMER_GROUP 

for Database Resource Manager, 25-4 
DEFAULT_CONSUMER_GROUP for Database 

Resource Manager, 25-29, 25-36 
defining 

chain steps, 27-41 
dependencies 

between schema objects, 16-17 

displaying, 16-23 
DIAGNOSTIC_DEST, 7-2 

DIAGNOSTIC_DEST initialization parameter, 8-6 
dictionary-managed tablespaces 

migrating SYSTEM to locally managed, 12-29 
Digital POLYCENTER Manager on NetView, 29-23 
direct-path INSERT 

benefits, 18-16 

how it works, 18-17 

index maintenance, 18-18 

locking considerations, 18-10 

logging mode, 18-18 

parallel INSERT, 18-17 

parallel load compared with parallel 
INSERT, 18-16, 18-17 

serial INSERT, 18-17 

space considerations, 18-19 
disabling 

chains, 27-45 

jobs, 27-11 

programs, 27-15 

SQL patch, 8-28 

window groups, 27-32 

windows, 27-27 
disabling recoverer process, 33-18 
dispatcher process (Dnnn), 4-19 



dispatcher processes, 4-11, 4-14 
DISPATCHERS initialization parameter 

setting attributes of, 4-10 

setting initially, 4-11 
distributedapplications 

distributing data, 31-1 
distributed databases 

administration overview, 29-16 

application development, 29-31, 31-1, 31-9 

client/server architectures, 29-4 

commit point strength, 32-6 

cost-based optimization, 29-33 

direct and indirect connections, 29-5 

distributed processing, 29-2 

distributed queries, 29-24 

distributed updates, 29-24 

forming global database names, 30-1 

global object names, 29-15, 30-1 

globalization support, 29-34 

location transparency, 29-31, 30-18 

management tools, 29-22 

managing read consistency, 33-19 

nodes of, 29-4 

overview, 29-1 

remote object security, 30-20 

remote queries and updates, 29-23 

replicated databases and, 29-3 

resumable space allocation, 17-10 

running in ARCHIVELOG mode, 11-3 

running in NOARGHIVELOG mode, 11-3 

scenarios, 30-24 

schema object name resolution, 29-27 

schema-dependent global users, 29-19 

schema-independent global users, 29-19 

security, 29-17 

site autonomy of, 29-16 

SQL transparency, 29-32 

starting a remote instance, 3-7 

transaction processing, 29-23 

transparency, 29-31 
distributed processing 

distributed databases, 29-2 
distributed queries, 29-24 

analyzing tables, 31-5 

application development issues, 31-2 

cost-based optimization, 31-3 

optimizing, 29-33 
distributed systems 

data encryption, 29-21 
distributed transactions, 29-25 

case study, 32-14 

commit point site, 32-5 

commit point strength, 32-6, 33-1 

committing, 32-6 

database server role, 32-4 

defined, 32-1 

DML and DDL, 32-2 

failure during, 33-17 

global coordinator, 32-4 

local coordinator, 32-4 
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lock timeout interval, 33-17 

locked resources, 33-17 

locks for in-doubt, 33-17 

manually overriding in-doubt, 33-6 

naming, 33-2, 33-7 

session trees, 32-3, 32-4, 32-5, 33-4 

setting advice, 33-7 

transaction control statements, 32-2 

transaction timeouts, 33-17 

two-phase commit, 32-14, 33-6 

viewing database links, 33-2 
distributed updates, 29-24 
DML error logging, inserting data with, 18-12 
DML. See data manipulation language 
DEIVING_SITE hint, 31-6 
DROP CLUSTER statement 

CASCADE CONSTRAINTS clause, 20-7 

dropping cluster, 20-7 

dropping cluster index, 20-7 

dropping hash cluster, 21-7 

INCLUDING TABLES clause, 20-7 
DROP DATABASE statement, 2-30 
DROP LOGFILE clause 

ALTER DATABASE statement, 10-12 
DROP LOGFILE MEMBER clause 

ALTER DATABASE statement, 10-13 
DROP SYNONYM statement, 22-18 
DROP TABLE statement 

about, 18-43 

CASCADE CONSTRAINTS clause, 18-44 

for clustered tables, 20-8 
DROP TABLESPACE statement, 12-24 
dropping 

chain steps, 27-46 

chains, 27-44 

columns 

marking unused, 18-24 
remove unused columns, 18-24 

columns in compressed tables, 18-25 

datafiles, 13-11 

job classes, 27-22 

jobs, 27-10 

programs, 27-14 

rules from chains, 27-45 

schedules, 27-17 

SQL patch, 8-28 

tempfiles, 13-11 

window groups, 27-31 

windows, 27-26 
dropping database links, 30-15 
dropping datafiles 

Oracle-managed, 15-17 
dropping tables 

CASCADE clause, 18-44 

consequences of, 18-44 
dropping tempfiles 

Oracle-managed, 15-17 
DUMP_ORPHAN_KEYS procedure, 23-4 

checking sync, 23-4 

DBMS_REPAIR package, 23-2 



example, 23-9 
recovering data, 23-5 
dumps, 8-5 



EMPHASIS resource allocation method, 25-13 
enabling 

chains, 27-43 

jobs, 27-11 

programs, 27-15 

window groups, 27-32 

windows, 27-27 
enabling recoverer process 

distributed transactions, 33-18 
encryption 

column, 18-6 

tablespace, 12-8 
encryption, transparent data, 2-44 
enterprise users 

definition, 20-19 
environment variables 

ORACLE_SlD, 2-5 
error logging, DML 

inserting data with, 18-12 
errors 

alert log and, 7-1 

assigning names with 

PRAGMA_EXCEPTION_INIT, 31-9 

critical, 8-1 

exception handler, 31-8 

integrity constrain violation, 31-2 

ORA-00028, 4-23 

ORA-01090, 3-9 

ORA-01173, 9-7 

ORA-01176, 9-7 

ORA-01177, 9-7 

ORA-01578, 13-12 

ORA-01591, 33-17 

ORA-02049, 33-17 

ORA-02050, 33-6 

ORA-02051, 33-6 

ORA-02054, 33-6 

ORA-1215, 9-7 

ORA-1216, 9-7 

RAISE_APPLICATION_ERROR() 
procedure, 31-8 

remote procedure, 31-8 

rollback required, 31-2 

trace files and, 7-1 

when creating a database, 2-30 

when creating control file, 9-7 

while starting a database, 3-6 

while starting an instance, 3-6 
event message 

passing to event-based job, 27-39 
event schedule 

altering, 27-38 

creating, 27-38 
event-based job 
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altering, 27-38 

creating, 27-37 

passing event messiiges to, 27-39 
events (Scheduler) 

overview, 25-5 

using, 27-33 
exception handler, 31-8 
EXCEPTION keyword, 31-8 
exceptions 

assigning names with 

PRAGMA_EXCEPTION_INlT, 31-9 

integrity constraints, 16-14 

user-defined, 31-9 
executing 

remote external jobs, 28-13 
execution pliins 

analyzing tor distributed queries, 31-7 
export operations 

restricted mode and, 3-6 
expressions, calendaring, 27-17 
EXTENT MANAGEMENT LOCAL clause 

CREATE DATABASE, 2-15 
extents 

allocating cluster extents, 20-6 

allocating for tables, 18-22 

data dictionary views for, 17-32 

deallocating cluster extents, 20-6 

displaying free extents, 17-34 
external jobs, 26-11 

capturing standard error output for, 27-9 

creating remote, 27-6 
external procedures 

managing processes for, 4-21 
external tables 

altering, 18-62 

creating, 18-59 

defined, 18-58 

dropping, 18-63 

privileges required, 18-53 

uploading data example, 18-60 



fault diagnosability infrastructure, 8-1 

features 

new, XX ix 
features, new, xxix 
file mapping 

examples, 13-23 

how it works, 13-16 

how to use, 13-20 

overview, 13-16 

structures, 13-18 

views, 13-22 
file system 

used for Oracle-managed files, 15-2 
HLE_MAPP1NG initialization parameter, 13-20 
filenames 

Oracle-managed files, 15-6 
files 



creating Oracle-managed files, 15-5, 15-17 
finalizing 

an incident package, definition, 8-31 
FIX_COEEUPT_BLOCKS procedure 

DBMS_REPA1R, 23-2 

example, 23-8 

marking blocks corrupt, 23-5 
fixed user database links 

advantages and disadvantages, 29-12 

creating, 30-8 

definition, 20-11 

example, 29-13 
flash recovery area 

initialization parameters to specify, 2-26 

with Oracle managed files, 15-4 
Flashback Drop 

about, 18-44 

purging recycle bin, 18-47 

querying recycle bin, 18-46 

recycle bin, 18-45 

restoring objects, 18-47 
Flashback Table 

overview, 18-43 
flood-controlled incidents 

defined, 8-3 

viewing, 8-17 
FMON background process, 13-17 
FMPUTL external process 

used for file mapping, 13-17 
FORCE clause 

COMMIT statement, 33-8 

ROLLBACK statement, 33-8 
FORCE LOGGING clause 

CREATE CONTROLFILE, 2-22 

CREATE DATABASE, 2-22 

CREATE TABLESPACE, 12-14 

performance considerations, 2-23 
FORCE LOGGING mode, 18-18 
forcing 

COMMIT or ROLLBACK, 33-3, 33-6 
forcing a log switch, 10-13 

using ARCH1VE_LAG_TARGET, 10-8 

with the ALTER SYSTEM statement, 10-13 
forget phase 

in two-phase commit, 32-11 
free space 

listing free extents, 17-34 

tablespaces and, 12-46 
function-based indexes, 19-10 



generic connectivity 

definition, 29-4 
global cache service (LMS), 4-19 
global coordinators, 32-4 

distributed transactions, 32-4 
global database consistency 

distributed databases and, 32-10 
global database links, 29-10 
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creating, 30-8 
global database names 

changing the domain, 30-3 

database links, 29-8 

enforcing for database links, 29-10 

enforcing global naming, 30-2 

forming distributed database names, 30-1 

impact of changing, 29-30 

querying, 30-3 
global object names 

database links, 29-25 

distributed databases, 30-1 
global users, 30-26 

schema-dependent in distributed systems, 29-19 

schema-independent in distributed 
systems, 29-19 
GLOB AL_NAME view 

using to determine global database name, 30-3 
GLOBAL_NAMES initialization parameter 

database links, 29-9 
globalization support 

client/server architectures, 29-34 

distributed databases, 29-34 
GRANT statement 

SYSOPER/SYSDBA privileges, 1-24 
granting privileges and roles 

SYSOPER/SYSDBA privileges, 1-24 
growth trends 

of database objects, 17-36 
GV$DBL1NK view, 30-17 

H 

hash clusters 

advantages and disadvantages, 21-1 

altering, 21-7 

choosing key, 21-4 

contrasted with index clusters, 21-1 

controlling space use of, 21-4 

creating, 21-2 

data dictionary views reference, 21-8 

dropping, 21-7 

estimating storage, 21-7 

examples, 21-6 

hash function, 21-1, 21-2, 21-3, 21-5 

HASH IS clause, 21-3,21-5 

HASHKEYS clause, 21-3, 21-6 

single-table, 21-4 

SIZE clause, 21-5 

sorted, 21-3 
hash functions 

for hash cluster, 21-1 
health checks, 8-2 
Health Monitor, 8-19 

checks, 8-19 

generating reports, 8-22 
running, 8-21 
viewing reports, 8-22 
viewing reports using ADRCl, 8-24 
heterogeneous distributed systems 



definition, 29-3 
Heterogeneous Services 

overview, 29-3 
HI_SHARED_MEMORY_ADDRESS parameter, 5-19 
hints, 31-6 

DRrVING_SITE, 31-6 

NO_MERGE, 31-6 

using to tune distributed queries, 31-6 
HP Open View, 29-23 

I 

IBM NetView/6000, 29-23 
import operations 

restricted mode and, 3-6 
incident package 

creating, editing and uploading custom, 8-30 

customizing, 8-36, 8-37 

defined, 8-2 

viewing, 8-37 
incident packaging service, 8-2 
incidents 

about, 8-3 

flood-controlled, 8-3 
viewing, 8-17 
index clusters. Sec clusters, 
indexes 

altering, 19-12 

analyzing, 16-2 

choosing columns to index, 19-3 

cluster indexes, 20-5, 20-6, 20-7 

coalescing, 19-5, 19-13 

column order for performance, 19-3 

creating, 19-6 

data dictionary views reference, 19-16 

disabling and dropping constraints cost, 19-6 

dropping, 19-4, 19-15 

estimating size, 19-4 

estimating space use, 17-36 

explicitly creating a unique index, 19-7 

function-based, 19-10 

guidelines for managing, 19-1 

invisible, 19-11,19-14 

keeping when disabling constraint, 16-12 

keeping when dropping constraint, 16-12 

key compression, 19-11 

limiting for a table, 19-4 

monitoring space use of, 19-14 

monitoring usage, 19-14 

parallelizing index creation, 19-5 

rebuilding, 19-5,19-13 

rebuih after direct-path INSERT, 18-18 

setting storage parameters for, 19-4 

shrinking, 17-28 

space used by, 19-14 

statement for creating, 19-7 

tablespace for, 19-4 

temporary segments and, 19-2 

validating structure, 16-3 

when to create, 19-3 
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index-organized tables 

analyzing, 18-57 

AS subquery, 18-53 

converting to heap, 18-58 

creating, 18-50 

described, 18-49 

INCLUDING clause, 18-52 

key compression, 18-53 

m.aintaining, 1 8-54 

ORDER BY clause, using, 18-58 

parallel creation, 18-53 

rebuilding with MOVE clause, 18-55 

storing nested tables, 18-51 

storing object types, 18-51 

threshold value, 18-52 
in-doubt transactions, 32-11 

after a system failure, 33-6 

automatic resolution, 32-12 

deciding how to handle, 33-5 

deciding whether to perform manual 
override, 33-6 

defined, 32-10 

manual resolution, 32-13 

manually committing, 33-8 

manually committing, example, 33-11 

manually overriding, 33-6, 33-8 

manually overriding, scenario, 33-11 

manually rolling back, 33-9 

overview, 32-11 

pending transactions table, 33-16 

purging rows from data dictionary, 33-9, 33-10 

recoverer process and, 33-18 

rolling back, 33-8, 33-9 

SCNs and, 32-14 

simulating, 33-17 

tracing session tree, 33-4 

viewing database links, 33-2 
INITIAL parameter 

cannot alter, 17-7, 18-21 

description, 17-6 
initialization parameter file 

and Automatic Storage Management, 3-3 

creating, 2-7 

creating by copying and pasting from alert 
log, 2-30 

creating for database creation, 2-7 

editing before database creation, 2-25 

individual parameter names, 2-25 

sample, 2-24 

server parameter file, 2-31 

understanding, 3-2 
initialization parameters 

ARCH1VE_LAG_TARGET, 10-8 

BUFFER _POOL_KEEP, 5-16 

BUFFER _POOL_RECYCLE, 5-16 

changing, 2-36 

clearing, 2-38 

COMMIT_POINT_STRENGTH, 32-6, 33-1 

CONTROL_FILES, 2-26, 9-2, 9-3 

DB_BLOCK_CHECKING, 23-4 



DB_BLOCK_CHECKSUM, 10-13, 13-12 

DB_BLOCK_SlZE, 2-27, 12-14 

DB_CACHE_SIZE, 12-14 

DB_DOMA, 2-25 

DB_DOMAlN, 2-26 

DB_FILES, 13-2 

DB_NAME, 2-25 

DB_nK_CACHE_SlZE, 12-14, 12-41 

DISPATCHERS, 4-11 

FILE_MAPP1NG, 13-20 

for buffer cache, 5-15 

GLOBAL .NAMES, 29-9 

HI_SHARED_MEMORY_ADDRESS, 5-19 

LOCK_SGA, 5-19 

LOG_ARCHlVE_DEST, 1 1-6 

LOG_ARCHlVE_DEST_fi, 11-6, 11-13 

LOG_ARCHlVE_DEST_STATE_)i, 11-9 

LOG_ARCHlVE_MAX_PROCESSES, 11-5 

LOG_ARCHiVE_MiN_SUCCEED_DEST, 11-11 

LOG_ARCHiVE_TRACE, 11-13 

MAX_DUMP_F1LE_SIZE, 7-2 

OPEN_LINKS, 30-16 

PROCESSES, 2-28 

REMOTE_LOGlN_PASSWORDFlLE, 1-23 

REMOTE_OS_AUTHENT, 29-12 

resetting, 2-38 

RESOURCE_MANAGER_PLAN, 25-30 

server parameter file and, 2-31, 2-39 

SET SQL_TRACE, 7-3 

setting, 2-36 

shared server and, 4-6 

SHARED_MEMORY_ADDRESS, 5-19 

SHARED .SERVERS, 4-8 

SORT_AREA_SIZE, 19-2 

SPFILE, 2-36, 3-3 

SQL_TRACE, 7-1 

STATISnCS.LEVEL, 18-19 

UNDO_MANAGEMENT, 2-17 

UNDO_TABLESPACE, 2-29, 14-2 

USE_iNDIRECT_DATA_BUFFERS, 5-19 
INITRANS parameter 

altering, 18-21 

guidelines for setting, 17-4 
INSERT statement 

with DML error logging, 18-12 
installing 

patches, 1-6 
instances 

aborting, 3-10 

shutting down immediately, 3-9 

shutting down normally, 3-9 

transactional shutdown, 3-10 
integrity constraints 

See also constraints 

cost of disabling, 19-6 

cost of dropping, 19-6 

creating indexes associated with, 19-8 

dropping tablespaces and, 12-24 

ORA-02055 constraint violation, 31-2 
INTERNAL username 
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connecting for shutdown, 3-0 
invisible indexes, 10-11, 10-14 
JOT. See index-orgiinized tables. 
IPS, 8-2 



job classes 

altering, 27-22 

creating, 27-22 

dropping, 27-22 

overview, 26-8 

using, 27-21 
ob coordinator, 26-14 
ob recovery [Scheduler), 28-18 
OB_QUEUE_PROCESSES initializiition 

parameter, A-1 
jobs 

altering, 27-8 

copying, 27-7 

creatiiAg, 27-2 

creating for chains, 27-44 

disabling, 27-11 

dropping, 27-10 

enabling, 27-11 

external, 26-11 

failed Scheduler, 28-17 

lightweight jobs, 26-5 

overview, 26-4 

priorities, 28-12 

remote external 
about, 26-12 
creating, 27-6 
running, 27-5 

running, 27-8 

stopping, 27-9 

using, 27-1 

viewing information on running, 28-7 
join views 

definition, 22-2 

DELETE statements, 22-8 

key-preserved tables in, 22-7 

modifj'ing, 22-5 

rules for modifying, 22-7 

updating, 22-5 
joins 

statement transparency in distributed 
databases, 30-23 
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key compression, 18-53 

indexes, 19-11 
key-preserved tables 

in join views, 22-7 

in outerjoins, 22-10 
keys 

cluster, 20-1,20-4 



large objects, 18-9 
lightweight jobs 

example, 27-5 

example of setting attributes, 28-26 

examples, 27-5, 28-20 
links 

See database links 
LIST CHAINED ROWS clause 

of ANALYZE statement, 16-4 
listing database links, 30-16, 33-2, 33-4 
loading data 

using external tables, 18-60 
LOBs, 18-9 

storage parameters for, 17-7 
local coordinators, 32-4 

distributed transactions, 32-4 
locally managed tablepsaces 

shrinking, temporary, 12-23 
locally managed tablespaces, 12-3 

automatic segment space management in, 12-5 

DBMS_SPACE_ADM1N package, 12-26 

detecting and repairing defects, 12-26 

migrating SYSTEM from 

dictionary-managed, 12-29 

tempfiles, 12-11 

temporary, creating, 12-11 
location transparency in distributed databases 

creating using synonyms, 30-20 

creating using views, 30-19 

restrictions, 30-23 

using procedures, 30-22 
lock timeout interval 

distributed transactions, 33-17 
LOCK_SGA parameter, 5-19 
locks 

in-doubt distributed transactions, 33-17 

monitoring, 7-7 
log 

window (Scheduler), 27-23 
log sequence number 

control files, 10-3 
log switches 

description, 10-3 

forcing, 10-13 

log sequence numbers, 10-3 

multiplexed redo log files and, 10-5 

privileges, 10-13 

using ARCH1VE_LAG_TARGET, 10-8 

waiting for archiving to complete, 10-5 
log writer process (LGWR), 4-19 

multiplexed redo log files and, 10-5 

online redo logs available for use, 10-2 

trace files and, 10-5 

writing to online redo log files, 10-2 
LOG_ARCHlVE_DEST initialization parameter 

specifying destinations using, 1 1-6 
LOG_ARCHlVE_DEST_ii initialization 
parameter, 11-6 

REOPEN attribute, 11-13 



lndex-14 



LOG_ARCHIVE_DEST_STATE_)iLriitializiition 

parameter, 11-9 
LOG_ARCHIVE_DUPLEX_DEST initialization 
parameter 

specifying destinations using, 11-6 
LOG_AECHIVE_MAX_PROCESSES initialization 

parameter, 11-5 
LOG_ARCHIVE_MIN_SUCCEED_DESTinitialization 

parameter, 11-11 
LOG_ARCHIVE_TRACE initialization 

parameter, 11-13 
LOGGING clause 

CREATE TABLESPACE, 12-14 
logging mode 

direct-path INSERT, 18-18 

NOARCHIVELOG mode and, 18-18 
logical corruptions from DBMS_REPA1R, 23-4 
logical volume managers 

mapping files to physical devices, 13-15, 13-24 

used for Oracle-managed files, 15-2 
LOGON trigger 

setting resumable mode, 17-12 
logs 

job, 28-8 

window (Scheduler), 27-23,28-8 
LONG columns, 30-24 
LONG RAW columns, 30-24 

M 

m.aintenance window 

creating, 24-4 

definition, 24-1 

MAINTENANCE_WINDOW_GROUP, 24-2 

modifj'ing, 24-4 

predefined, 24-7 

removing, 24-5 
maintenance windows 

Scheduler, 24-2 
managing 

memory, 5-1 

space threshold alerts for the undo 
tablespace, 14-11 
managing datafiles, 13-1 
managing sequences, 22-12 
managing synonyms, 22-17 
managing tables, 18-1 
managing views, 22-1 
manual archiving 

in ARCHIVELOG mode, 11-5 
manual overrides 

in-doubt transactions, 33-8 
MAX_DUMP_F1LE_SIZE initialization 

parameter, 7-2 
MAXDATAFILES parameter 

changing, 9-5 
MAXINSTANCES, 9-5 
MAXLOGFILES parameter 

changing, 9-5 

CREATE DATABASE statement, 10-7 



MAXLOGHISTORY parameter 

changing, 9-5 
MAXLOGMEMBERS parameter 

changing, 9-5 

CREATE DATABASE statement, 10-7 
MAXTRANS parameter 

ahering, 18-21 
media recovery 

effects of archiving on, 1 1-2 
memory 

extended buffer cache (32-bit), 5-19 

managing, 5-1 

overview of architecture of, 5-2 

system global area (SGA) 

initialization parameters, 5-19 
locking into physical memory, 5-19 
starting address, 5-19 
memory management 

about, 5-1 

automatic, 5-1, 5-4 

data dictionary views reference, 5-21 
MEMORY_MAx1tARGET parameter, 5-3 
MEMORY_TARGET parameter, 5-3 
migrated rows 

eliminating from table, procedure, 16-4 
MINEXTENTS parameter 

cannot alter, 17-7, 18-21 

description, 17-6 
mirrored files 

control files, 2-27, 9-2 

online redo log, 10-5 

online redo log location, 10-6 

online redo log size, 10-7 
MISSING datafiles, 9-7 
monitoring 

chains, 28-12 

performance, 7-6 
MONITORING clause 

CREATETABLE, 18-19 
MONITORING USAGE clause 

of ALTER INDEX statement, 19-14 
mounting a database, 3-5 
moving control files, 9-4 
multiple temporary tablespaces, 12-12, 12-13 
multiplexed control files 

importance of, 9-2 
multiplexing 

archived redo logs, 11-6 

control files, 9-2 

redo log file groups, 10-4 

redo log files, 10-4 

N 

name resolution in distributed databases 
database links, 29-25 
impact of global name changes, 29-30 
procedures, 29-29 
schema objects, 29-15, 29-27 
svnonvms, 29-29 
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views, 29-29 

when global database name is complete, 29-26 

when global database name is partial, 29-26 

when no global database name is specified, 29-26 
named user limits 

setting initially, 2-30 
nested tables 

storage parameters for, 17-7 
networks 

connections, minimizing, 30-11 

distributed databases use of, 29-1 
new features, xxix 
NEXT parameter 

altering, 17-7, 18-21 
NEXTVAL pseudo-column, 22-14 

restrictions, 22-15 
NO_DATA_FOUND ke\rv^'ord, 31-8 
NO_MERGE hint, 31-6 
NOARCHIVELOG mode 

archiving, 11-2 

definition, 11-2 

dropping datafiles, 13-7 

LOGGING mode and, 18-18 

media failure, 11-2 

no hot backups, 11-2 

running in, 11-2 

switching to, 11-4 

taking datafiles offline in, 13-7 
NOCACHE option 

CREATE SEQUENCE statement, 22-16 
NOLOGGING clause 

CREATE TABLESPACE, 12-14 
NOLOGGING mode 

direct-path INSERT, 18-18 
NOMOUNT clause 

STARTUP command, 3-5 
normal transmission mode 

definition, 11-9 
Novell NetWare Management System, 29-23 



object privileges 

for external tables, 18-63 
objects 

See also schema objects 
offline tablespaces 

priorities, 12-15 

taking offline, 12-15 
online redefinition of tables, 18-26 

abort and cleanup, 18-33 

examples, 18-36 

features of, 18-27 

intermediate synchronization, 18-32 

redefining a single partition, 18-34 
rules for, 18-35 

restrictions, 18-33 

with DBMS_REDEF1NIT10N, 18-28 
online redo log files 

See also online redo logs 



online redo togs 

See also redo log files 

creating groups, 10-9 

creating members, 10-10 

data dictionary views reference, 10-15 

dropping groups, 10-11 

dropping members, 10-11 

forcing a log switch, 10-13 

guidelines for configuring, 10-4 

INVALID members, 10-12 

location of, 10-6 

managing, 10-1 

moving files, 10-10 

number of files in the, 10-7 

optimum configuration for the, 10-7 

renaming files, 10-10 

renaming members, 10-10 

specifying ARCHIVE.LAG.TARGET, 10-8 

STALE members, 10-12 
onUne segment shrink, 17-28 
OPEN_LINKS initialization parameter, 30-16 
opening windows, 27-25 
operating system authentication, 1-18 
operating systems 

database administrators requirements for, 1-13 

renaming and relocating files, 13-8 
ORA_TZHLE environment variable 

specifying time zone file for database, 2-21 
ORA-01013 error message, 3-11 
ORA-02055 error 

integrity constraint violation, 31-2 
ORA-02067 error 

rollback required, 31-2 
Oracle Call Interface. See OCI 
Oracle Data Guard 

support by the Scheduler, 26-13, 28-29 
Oracle Database 

release numbers, 1-11 
Oracle Database users 

types of, 1-1 
Oracle Enterprise Manager, 3-2 
Oracle home 

cloning, 1-6 
Oracle Managed Files feature 

See also Oracle-managed files 
Oracle Net 

service names in, 11-10 

transmitting archived logs via, 11-10 
Oracle Scheduler 

scheduling tasks with, 27-1 
Oracle Universal Installer, 2-2 
Oracle wallet, 12-8, 18-6 
ORACLE_SID environment variable, 2-5 
Oracle-managed files 

adding to an existing database, 15-23 

behavior, 15-17 

benefits, 15-3 

CREATE DATABASE statement, 15-7 

creating, 15-5 

creating control files, 15-14 
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creating datafiles, 15-11 

creating online redo log files, 15-16 

creating temptiles, 15-13 

described, 15-1 

dropping datafile, 15-17 

dropping online redo log files, 15-18 

dropping tempfile, 15-17 

initialization parameters, 15-3 

introduction, 2-18 

naming, 15-6 

renaming, 15-18 

scenarios for using, 15-18 
oraenv and coraenv, 1-8 
ORAPWD utility, 1-21 
ORGANIZATION EXTERNAL clause 

of CREATE TABLE, 18-59 
orphan key table 

example of building, 23-7 
OSDBA group, 1-18 
OSOPER group, 1-18 
OTHER_GROUPS 

for Database Resource Manager, 25-4 
OTHER_GROUPS for Database Resource 

Manager, 25-17, 25-10, 25-35 
outer joins, 22-0 

key-preserved tables in, 22-10 
overlapping windows, 27-28 



package 

See also incident package 
package, incident 

defined, 8-2 
packages 

DBMS_FILE_TRANSFER, 13-12 

DBMS_METADATA, 16-21 

DBMS_REDEFINITION, 18-28, 18-42 

DBMS_REPAIR, 23-1 

DBMS_RESOURCE_MANAGER, 25-3, 25-8, 25-9, 
25-2! 

DBMS_RESOURCE_MANAGER_PRIVS, 25-8, 
25-9 

DBMS_RESUMABLE, 17-13 

DBMS_SPACE, 17-30, 17-31 

DBMS_STATS, 16-3, 18-19 

DBMS_STORAGE_MAP, 13-21, 13-22 
packaging and uploading problems, 8-33 
parallel execution 

managing, 4-10 

parallel hints, 4-20 

parallelizing index creation, 19-5 

resumable space allocation, 17-10 
parallel hints, 4-20 
PARALLEL_DEGREE_LlMlT_ABSOLUTE resource 

allocation method, 25-13 
parallelizing table creation, 18-4, 18-11 
parameter files 

See also initialization parameter file, 
partitioned tables 



redefining partitions online, 18-34 
rules for, 18-35 
password 

setting for SYSTEM account in CREATE 
DATABASE statement, 2-15 

setting SYS in CREATE DATABASE 
statement, 2-15 
password file 

adding users, 1-23 

creating, 1-21 

ORAPWD utility, 1-21 

removing, 1-25 

setting REMOTE_LOGIN_PASSWORD, 1-23 

viewing members, 1-24 
password file authentication, 1-19 
passwords 

case sensitivity of, 1-16, 1-20 

default for SYS and SYSTEM, 1-13 

password file, 1-23 

setting REMOTE_LOGIN_PASSWORD 
parameter, 1-23 
patches, installing, 1-6 
PCTINCREASE parameter, 18-21 

altering, 17-7 
pending area for Database Resource Manager 
plans, 25-20 

validating plan schema changes, 25-18 
pending transaction tables, 33-16 
performance 

index column order, 19-3 

location of datafiles and, 13-4 

monitoring, 7-6 
PGA_AGGREGATE_TARGET initialization 

parameter, 5-19 
plan schemas for Database Resource Manager, 25-7, 
25-30, 25-36 

validating plan changes, 25-18 
plans for Database Resource Manager 

examples, 25-31 
PL /SQL 

replaced views and program units, 22-4 
PRAGMA_EXCEPTION_INIT procedure 

assigning exception names, 31-9 
predefined user accounts, 2-43 
prepare phase 

abort response, 32-0 

in two-phase commit, 32-8 

prepared response, 32-8 

read-only response, 32-9 

recognizing read-only nodes, 32-9 

steps, 32-9 
prepare/commit phases 

effects of failure, 33-17 

failures during, 33-6 

locked resources, 33-17 

pending transaction table, 33-16 
prepared response 

two-phase commit, 32-8 
prerequisites 

for creating a database, 2-4 
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PRIMARY KEY constraints 

associated indexes, 19-8 

dropping associated indexes, 19-15 

enabling on creation, 19-8 

foreign key references when dropped, 16-13 

indexes associated with, 19-8 
priorities 

job, 28-12 
private database links, 29-10 
private synonyms, 22-17 
privileges 

adding redo log groups, 10-9 

altering indexes, 19-12 

altering tables, 18-20 

closing a database link, 31-2 

creating database links, 30-6 

creating tables, 18-8 

creating tablespaces, 12-2 

database administrator, 1-13 

dropping indexes, 19-15 

dropping online redo log members, 10-12 

dropping redo log groups, 10-12 

dropping tables, 18-43 

enabling and disabling triggers, 16-8 

for external tables, 18-63 

forcing a log switch, 10-13 

managing with procedures, 30-23 

managing with synonyms, 30-21 

managing with views, 30-20 

manually archiving, 11-5 

renaming objects, 16-16 

renaming redo log members, 10-10 

RESTRICTED SESSION system privilege, 3-6 

Scheduler, 28-1 

sequences, 22-13, 22-16 

setting chain (Scheduler), 28-2 

synonyms, 22-17, 22-18 

taking tablespaces offline, 12-15 

truncating, 16-7 

using a view, 22-4 

using sequences, 22-14 

views, 22-1, 22-3, 22-12 
privileges, Scheduler, 28-30 
problem activity log 

adding comments to, 8-14 
problems 

about, 8-3 

adding comments to activity log, 8-14 
problems (critical errors) 

packaging and uploading, 8-33 
procedures 

external, 4-21 

location transparency in distributed 
databases, 30-21 

name resolution in distributed databases, 29-29 

remote calls, 29-33 
process monitor (PMON), 4-19 
processes 

See also server processes 
PROCESSES initialization parameter 



setting before database creation, 2-28 
PRODUCT_COMPONENT_VERSION view, 1-12 
program global area (PGA), 5-2 
program global areas, 5-2 
programs 

altering, 27-14 

creating, 27-12 

disabling, 27-15 

dropping, 27-14 

enabling, 27-15 

overview, 26-3 

using, 27-12 
public database links, 29-10 

connected user, 30-25 

fixed user, 30-25 
public fixed user database links, 30-25 
public synonyms, 22-17 
PURGE_LOST_DB_ENTRY procedure 

DBMS.TRANSACnON package, 33-10 

Q 

queries 

distributed, 29-24 

distributed application development issues, 31-2 

location transparency and, 29-32 

remote, 29-23 
quiescing a database, 3-11 
quotas 

tablespace, 12-2 



RAISE_APPLICATION_ERROR() procedure, 31- 
read consistency 

managing in distributed databases, 33-19 
read-only database 

opening, 3-8 
read-only response 

two-phase commit, 32-9 
read-only tables, 18-25 
read-only tablespaces 

datafile headers when rename, 12-23 

delaying opening of datafiles, 12-20 

making read-only, 12-17 

making writable, 12-19 

WORM devices, 12-19 
Real Application Clusters 

allocating extents for cluster, 20-6 

sequence numbers and, 22-13 

threads of online redo log, 10-1 
rebuilding indexes, 19-13 

costs, 19-5 

online, 19-13 
reclaiming unused space, 17-15 
RECOVER clause 

STARTUP command, 3-7 
recoverer process 

disabling, 33-18 

distributed transaction recovery, 33-18 
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eniibling, 33-18 

pending triinsiiction table, 33-18 
recoverer process (RECO), 4-19 
recovering 

Scheduler jobs, 28-18 
recovery 

creating new control files, 9-5 
Recovery Manager 

starting a database, 3-2 

starting an instance, 3-2 
recycle bin 

about, 18-45 

purging, 18-47 

renamed objects, 18-45 

restoring objects from, 18-47 

viewing, 18-46 
redefining tables online 

See online redefinition of tables 
redo log files 

See also online redo logs 

active (current), 10-3 

archiving, 11-2 

available for use, 10-2 

circular use of, 10-2 

clearing, 10-5,10-14 

contents of, 10-2 

creating as Oracle-managed files, 15-16 

creating as Oracle-managed files, example, 15-21 

creating groups, 10-9 

creating members, 10-9, 10-10 

distributed transaction information in, 10-2 

dropping groups, 10-11 

dropping members, 10-11 

group members, 10-4 

groups, defined, 10-4 

how many in redo log, 10-7 

inactive, 10-3 

instance recovery use of, 10-1 

legal and illegal configurations, 10-5 

LGWR and the, 10-2 

log switches, 10-3 

maximum number of members, 10-7 

members, 10-4 

mirrored, log switches and, 10-5 

multiplexed, 10-4, 10-5 

online, defined, 10-1 

planning the, 10-4, 10-8 

redo entries, 10-2 

requirements, 10-5 

specifying at database creation, 15-8 

storing separately from datafiles, 13-4 

threads, 10-1 

unavailable when database is opened, 3-5 

verifying blocks, 10-13 
redo logs 

See also online redo log 

See also redo log files 
redo records, 10-2 

LOGGING and NOLOGGING, 12-14 
referential integrity 



distributed database application 
development, 31-2 
release number format, 1-11 
releases, 1-11 

checking the Oracle Database release 
number, 1-12 
relocating control files, 9-4 
remote connections 

connecting as SYSOPER/SYSDBA, 1-15 

password files, 1-23 
remote data 

querying, 30-23 

updating, 30-23 
remote externaljobs 

about, 26-12 

creating, 27-6 

credentials, 26-11 

executing, 28-13 

running, 27-6 

scheduler agent setup, 28-14 
remote procedure calls, 29-33 

distributed databases and, 29-33 
remote queries 

distributed databases and, 29-23 
remote transactions, 29-24 

defined, 29-24 
REMOTE_LOGIN_PASSWOEDFILE initialization 

parameter, 1-23 
REMOTE_OS_AUTHENT initialization parameter 

connected user database links, 29-12 
RENAME statement, 16-16 
renaming control files, 9-4 
renaming files 

Oracle-managed files, 15-18 
REOPEN attribute 

LOG_ARCHlVE_DEST_fi initialization 
parameter, 11-13 
repair table 

example of building, 23-6 
repairing data block corruption 

DBMS_REPAIR, 23-1 
repeat interval, schedule, 27-17 
RESIZE clause 

for single-file tablespace, 12-21 
resource allocation methods 

active session pool, 25-13 

ACn VE_SESS_POOL_MTH, 25- 1 3 

CPU resource, 25-13 

EMPHASIS, 25-13 

limit on degree of parallelism, 25-13 

PARALLEL_DEGREE_LlMIT_ABSOLUTE, 25-13 

PARALLEL_DEGREE_L1M1T_MTH, 25-13 

QUEUEING_MTH, 25-13 

queuing resource allocation method, 25-13 

ROUND-ROBIN, 25-12 
resource consumer groups, 25-3 

changing, 25-21 

creating, 25-12 

DEFAULT_CONSUMER_GROUP, 25-4, 25-29, 
25-36 
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deleting, 25-36 

griintiiig the switch privilege, 25-28 

managing, 25-20, 25-27 

OTHER_GROUPS, 25-4, 25-17, 25-10, 25-35 

parameters, 25-12 

revoking the switch privilege, 25-29 

setting initial, 25-21 

switching a session, 25-21 

switching sessions for a user, 25-22 

SYS_GROUP, 25-35 

updating, 25-36 
Resource Manager 

AUTO_TASK_CONSUMER_GROUP consumer 
group, 24-5 
resource plan directives, 25-3, 25-18 

deleting, 25-37 

specifying, 25-14 

updating, 25-37 
resource plans, 25-3, 25-6 

creating, 25-9 

DEFAULT_MAINTENANCE_PLAN, 24-6 

DELETE_PLAN_CASCADE, 25-36 

deleting, 25-36 

examples, 25-31 

parameters, 25-13 

plan schemas, 25-7, 25-30, 25-36 

SYSTEM_PLAN, 25-34 

top plan, 25-18, 25-30 

updating, 25-36 

validating, 25-18 
RESOURCE_MANAGER_PLAN initialization 

parameter, 25-30 
RESTRICTED SESSION system privilege 

restricted mode and, 3-6 
result cache 

and the shared pool size, 5-17 

setting size of, 5-18 
RESULT_CACHE_SIZE initialization 

parameter, 5-18 
resumable space allocation 

correctable errors, 17-9 

detecting suspended statements, 17-12 

disabling, 17-10 

distributed databases, 17-10 

enabling, 17-10 

example, 17-14 

how resumable statements work, 17-8 

naming statements, 17-12 

parallel execution and, 17-10 

resumable operations, 17-9 

setting as default for session, 17-12 

timeout interval, 17-11, 17-12 
RESUMABLE_TlMEOUT Initialization Parameter 

setting, 17-11 
RESUMABLE_TlMEOUT initialization 

parameter, 17-8 
retention guarantee (for undo), 14-4 
reversing table changes, 18-42 
RMAN. See Recovery Manager. 
roles 



DBA role, 1-14 

obtained through database links, 29-15 
ROLLBACK statement 

FORCE clause, 33-8, 33-9 

forcing, 33-6 
rollbacks 

ORA-02, 31-2 
ROUND-ROBIN resource allocation method, 25-12 
rows 

listing chained or migrated, 16-4 
rules 

adding to a chain, 27-42 

dropping from chains, 27-45 
running 

chains, 27-45 

jobs, 27-8 

SQL Repair Advisor, 8-26 



Sample Schemas 

description, 2-45 
savepoints 

in-doubt transactions, 33-8, 33-9 
Scheduler 

administering, 28-1 

architecture, 26-13 

configuring, 28-1 

credentials for remote external jobs, 26-11 

data dictionary views reference, 28-31 

examples of using, 28-19 

import and export, 28-16 

maintenance windows, 24-2 

monitoring and managing, 28-7 

overview, 26-1 

scheduling tasks with, 27-1 

security, 28-13 

support for Oracle Data Guard, 26-13, 28-29 

using in RAG, 26-16 
Scheduler agent 

defined, 26-12 
scheduler agent 

setup, 28-14 
Scheduler objects, naming, 27-1 
Scheduler privileges reference, 28-30 
Scheduler privileges, setting, 28-1 
schedules 

altering, 27-16 

creating, 27-16 

dropping, 27-17 

overview, 26-4 

using, 27-15 
scheduling database tasks, 27-1 
schema objects 

analyzing, 16-2 

creating multiple objects, 16-1 

data dictionary views reference, 16-22 

defining using DBMS_METADATA 
package, 16-21 



dependencies between, 16-17 
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distributed database naming conventions 
tor, 29-15 

global names, 29-15 

listing by type- 16-22 

name resolution in distributed databases, 29-15, 
29-27 

name resolution in SQL statements, 16-19 

privileges to rename, 16-16 

referencing with synonyms, 30-20 

renaming, 16-16 

validating structure, 16-3 

viewing information, 16-21, 17-31 
schema objects space usage 

data dictionary views reference, 17-32 
SCN. See system change number, 
SCOPE clause 

ALTER SYSTEM SET, 2-36 
scripts, authenticating users in, 2-44 
SEC_CASE_SENSITIVE_LOGON initialization 

parameter, 1-16, 1-20 
security 

accessing a database, 6-1 

administrator of, 6-1 

centralized user management in distributed 
databases, 29-19 

database security, 6-1 

distributed databases, 29-17 

establishing policies, 6-1 

privileges, 6-1 

remote objects, 30-20 

Scheduler, 28-13 

using synonyms, 30-21 
Segment Advisor, 17-16 

configuring Scheduler job, 17-27 

invoking with Enterprise Manager, 17-18 

invoking with PL/SQL, 17-19 

running manually, 17-17 

viewing results, 17-21 

views, 17-28 
SEGMENT_FIX_STATUS procedure 

DBMS_REPAIR, 23-2 
segments 

available space, 17-31 

data dictionary views for, 17-32 

deallocating unused space, 17-15 

displaying information on, 17-32 

shrinking, 17-28 

storage parameters for temporary, 17-7 
SELECT statement 

FOR UPDATE clause and location 
transparency, 30-23 
SEQUENCE_CACHE_ENTR1ES parameter, 22-16 
sequences 

accessing, 22-14 

altering, 22-13 

caching sequence numbers, 22-15 

creating, 22-13,22-16 

CURRVAL, 22-15 

data dictionary views reference, 22-18 

dropping, 22-16 



managing, 22-12 

NEXTVAL, 22-14 

Oracle Real Applications Clusters and, 22-13 
SERVER parameter 

net service name, 30-13 
server parameter file 

and Automatic Storage Management, 3-3 

creating, 2-32 

defined, 2-31 

exporting, 2-38 

migrating to, 2-32 

recovering, 2-39 

RMAN backup, 2-38 

setting initialization parameter values, 2-36 

SPFILE initialization parameter, 2-36 

STARTUP command behavior, 2-32 

viewing parameter settings, 2-39 
server processes 

archiver (ARCn), 4-19 

background, 4-18 

checkpoint (CKPT), 4-19 

database writer (DBWn), 4-19 

dedicated, 4-1 

dispatcher (Dnnn), 4-19 

dispatchers, 4-11 

global cache service (LMS), 4-19 

log writer (LGWR), 4-19 

monitoring locks, 7-7 

process monitor (PMON), 4-19 

recoverer (RECO), 4-19 

shared server, 4-2 

system monitor (SMON), 4-19 

trace files for, 7-1 
server-generated alerts, 7-4 
servers 

role in two-phase commit, 32-4 
service names 

database links and, 30-10 
services 

application, 2-40 

application, configuring, 2-42 

application, deploying, 2-41 

application, using, 2-42 
session trees for distributed transactions 

clients, 32-4 

commit point site, 32-5, 32-6 

database servers, 32-4 

definition, 32-3 

global coordinators, 32-4 

local coordinators, 32-4 

tracing transactions, 33-4 
sessions 

active, 4-23 

inactive, 4-23 

setting advice for transactions, 33-7 

terminating, 4-22 
SET TIME_ZONE clause 

ALTER SESSION, 2-21 

CREATE DATABASE, 2-21 
SETTRANSACnON statement 
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naming transactions, 33-2 
setting 

Scheduler privileges, 28-1 
SGA 

See Also system global area 
SGA_MAX_S1ZE initialization parameter, 5-8 
SGA_TARGET initialization parameter, 5-8 
shared database links 

configuring, 30-12 

creating, 30-12 

dedicated servers, creating links to, 30-12 

determining whether to use, 30-11 

example, 29-14 

shared servers, creating links to, 30-13 
SHARED keyword 

CREATE DATABASE LINK statement, 30-12 
shared server, 4-2 

configuring dispatchers, 4-9 

data dictionary views reference, 4-14 

disabling, 4-8, 4-14 

initialization parameters, 4-6 

interpreting trace output, 7-3 

setting minimum number of servers, 4-8 

trace files for processes, 7-1 
shared SQL 

for remote and distributed statements, 29-24 
SHARED_MEMORY_ADDRESS parameter, 5-19 
shrinking segments online, 17-28 
SHUTDOWN command 

ABORT clause, 3-10 

IMMEDIATE clause, 3-9 

interrupting, 3-11 

NORMAL clause, 3-9 

TRANSACTIONAL clause, 3-10 
Simple Network Management Protocol (SNMP) 
support 

database management, 29-23 
single-file tablespaces 

description, 12-6 
single- in stance 

defined, 2-5 
single-table hash clusters, 21-4 
site autonomy 

distributed databases, 29-16 
SKIP_CORRUPT_BLOCKS procedure, 23-5 

DBMS_REPAIR, 23-2 

example, 23-9 
snapshot too old error, 14-4 
SORT_AREA_SIZE initialization parameter 

index creation and, 19-2 
space 

deallocating unused, 17-30 

reclaiming unused, 17-15 
space allocation 

resumable, 17-8 
space management 

data blocks, 17-4 

datatypes, space requirements, 17-31 

deallocating unused space, 17-15 

Segment Advisor, 17-15 



setting storage parameters, 17-5, 17-7 

shrink segment, 17-15 
SPACE_ERROR_INFO procedure, 17-12 
SPFILE initialization parameter, 2-36 

specifying from client machine, 3-3 
SQL 

submitting, 1-6 
SQL failure 

repairing with SQL Repair Advisor, 8-26 
SQL patch 

disabling, 8-28 

removing, 8-28 

viewing, 8-28 
SQL Repair Advisor 

about, 8-26 

repairing SQL failure with, 8-26 

running, 8-26 
SQL statements 

distributed databases and, 29-23 
SQL test case builder, 8-3 
SQL'Loader 

about, 1-25 
SQL'PluE, 1-6 

about, 1-7 

connecting with, 1-7 

starting, 3-4 

starting a database, 3-1 

starting an instance, 3-1 
SQL_TRACE initialization parameter 

trace files and, 7-1 
STALE status 

of redo log members, 10-12 
stalled chain (Scheduler), 27-47 
standby transmission mode 

definition of, 11-9 

Oracle Net and, 11-10 

RES processes and, 11-10 
starting a database, 3-1 

forcing, 3-6 

Oracle Enterprise Manager, 3-2 

recovery and, 3-7 

Recovery Manager, 3-2 

restricted mode, 3-5 

SQL'Plus, 3-1 

when control files unavailable, 3-5 

when redo logs unavailable, 3-5 
starting an instance 

automatically at system startup, 3-7 

database closed and mounted, 3-5 

database name conflicts and, 2-26 

forcing, 3-6 

mounting and opening the database, 3-5 

normally, 3-5 

Oracle Enterprise Manager, 3-2 

recovery and, 3-7 

Recovery Manager, 3-2 

remote instance startup, 3-7 

restricted mode, 3-5 

SQL'Plus, 3-1 

when control files unavailable, 3-5 
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when redo logs unavailiible, 3-5 

without mounting a database, 3-5 
startup 

allocation ot the SGA 
starting a, 5-19 
STARTUP command 

default behavior, 2-32 

NOMOUNT clause, 2-9, 3-5 

RECOVER clause, 3-7 

starting a database, 3-1, 3-4 
statement transparency in distributed database 

managing, 30-23 
statistics 

automatically collecting for tables, 18-19 
STATISTICS_LEVEL initialization parameter 

automatic statistics collection, 18-19 
steps, chain 

altering, 27-46 

dropping, 27-46 
stopping 

jobs, 27-9 
STORAGE clause 

See also storage parameters 
storage parameters 

applicable objects, 17-5 

BUFFER POOL, 17-6 

INITIAL, 17-6,18-21 

INITRANS, altering, 18-21 

MAXTRANS, altering, 18-21 

MINEXTENTS, 17-6, 18-21 

NEXT, 18-21 

PCTINCREASE, 18-21 

precedence of, 17-7 

setting, 17-5 

temporary segments, 17-7 
storage subsystems 

mapping files to physical devices, 13-15, 13-24 
stored procedures 

managing privileges, 30-23 

remote object security, 30-23 
submitting SQL and commands to the database, \-€ 
subqueries 

in remote updates, 29-24 

statement transparency in distributed 
databases, 30-23 
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temporary, 12-10, 12-13 
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setting alert, 17-2 
time zone 

files, 2-22 

setting for database, 2-21 
TNSNAMES.ORA tile, 1 1-7 
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REUSE STORAGE clause, 16-7 

vs. dropping table, 18-44 



tuning 

analyzing tables, 31-5 
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in-doubt distributed transactions, 33-6 
undo space 

data dictionary views reference, 14-11 
undo space management 

automatic undo management mode, 14-2 
Undo tablespace 

specifying at database creation, 15-9 
undo tablespace 

managing, 14-7 

managing space threshold alerts, 14-11 

sizing a fixed-size, 14-6 
undo tablespaces 

altering, 14-9 

creating, 14-8 

data dictionary views reference, 14-11 

dropping, 14-9 

monitoring, 14-12 
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